Can I decode passwd from token about jwt-cpp HOT 7 CLOSED

@laoshanxi No you can't or otherwise JWT would be pretty useless. The idea is that you can verify if the token was created by a system you control. Thats whats the algorithm is for. It checks if the key used to create the token is the same used to verify it.

from jwt-cpp.

Thanks for the response, understand that,

many user management system is not standalone, and it is not safe to store password with unsafe way, so I want to integrate JWT method with LDAP together, is there anyway?

Thanks

from jwt-cpp.

Normally you would have an endpoint (lets call it /api/auth) which is used to authenticate a user.
A client application sends username and password to this endpoint, the endpoint validates them and creates a jwt token which contains some way to identify the user (like username or an userid). It sends the token back to the client.

Now you have multiple other endpoints (e.g. /api/get_picture) which need to know whether the user is a valid one and has authenticated it self. In order to do that the client sends the jwt token it got before to the server and the server validates if the signature is valid (thats what the verifier does) and the token is not expired. If both are true you know for sure the user is allowed to access the ressource because the token can only be created by your auth endpoint and has not been modified (otherwise the signature would not match). You don't need the users password anymore, as the token is now kindof like a password.

This has a number of benefits:

• You don't need access to a central user database, which reduces load and makes implementing CDN's a lot easier
• You can degrade gracefully (if your auth server goes down, it does not matter as long as the token is valid)
• If a token gets leaked, its less critically than leaking a password since tokens are normally short lived

Now to the drawbacks:

• You can't logout a user without lots of the benefits of using tokens in the first place
• Authentication to a 3rd party backend gets harder as you only have the password on login.

If I understand you correctly, you need the users password to access a backend LDAP (note if you only need to auth against LDAP see above), in which case you have a couple of options:

• Store the user password in the token encrypted (you already have openssl linked for JWT so just do a AES over the password before you drop it in the token)
• Store a mapping of user => password in the servers memory (bad idea)
• Store the plaintext password in the token (easiest but worst idea)
• Use a shared LDAP user (might be an option depending on your app)

from jwt-cpp.

Thanks for the analysis, Yes, this is really what I am thinking,

I just got the point that JWT does not need a passwd so it called key instead of passwd.

In my case, there have a centre enterprise LDAP authentication and it apply all 3rd product integrate with that, so I am thinking to integrate with JWT with LDAP for user passwd verification.

The first option seems make sense, that when creating the token, use AES append to a claim and decode the claim in token verification.

Thanks very much

from jwt-cpp.

Dear Thalhammer,

When I build JWT auth app using this, how to build a multi-instance auth for HA usage, if I sync the jwt data between those instances, the token can still not verify across node, is this true?

from jwt-cpp.

@laoshanxi As long as you have the public key (rsa/ecdsa) or the symetric key (hmac) on every node and the clocks are mostly in sync it should be fine. It is one of the design goals to allow verification without runtime shared data.

from jwt-cpp.

Got it, thanks for the clarify.

from jwt-cpp.