JWT Login Security

Question

I am new to security and I am wondering if JWT is secure enough.

From what I have read online the flow goes like this:

1. Clients log in by sending their credentials to the identity provider.
2. The identity provider verifies the credentials; if all is OK, it retrieves the user data, generates a JWT containing user details and permissions that will be used to access the services, and it also sets the expiration on the JWT (which might be unlimited).
3. so on...

Wouldn't Part 1 be vulnerable as it is not encrypted or am I missing something?

Answer 1

Your understanding seems correct insofar that JWT / oath / wtv authentication protocol you're following doesn't itself provide any protection for the username / password.

Let's take a famous example of a Single-Sign-On (SSO) system: the Google Accounts login page.

For all intents and purposes, this follows the flow you describe in your question, the first step of which is to send your username and password up to the server. All of the wisdom of the internet tells you to look for the browser padlock before typing in your password, right?

I think that's also the answer to your question: the JWT workflow doesn't provide any protection for the password; you get that by doing Step 1 over HTTPS.

Answer 2

No, as described in Wikipedia:

"The tokens are signed by one party's private key (usually the server's), so that both parties (the other already being, by some suitable and trustworthy means, in possession of the corresponding public key) are able to verify that the token is legitimate."

Typical cryptographic algorithms used are HMAC with SHA-256 (HS256) and RSA signature with SHA-256 (RS256).

So the Part 1 is indeed encrypted and secure.

Answer 3

The image you provide doesn't explicitly suggest that the username & password is encrypted indeed. But it is common practice to do so regardless of what type of security scheme one uses.

Typically the password, if not the username as well, is first digested, --on client side (browser), using a trap-door or hash algorithm(SHA-256 and such..), --one should also be adding salt to further reduce collision attacks, then looked up for in the user database whether or not to grant access.

It is also supposed to be saved as such the first time one signs up. This is also the reason why forgotten credentials can't be provided back from the server even if the server trusts the client. It doesn't actually know the password.

If not done so, your credentials are leaked in the server in plaintext if nowhere else.

Answer 4

No, as long as the following precautions are taken:

1. The password is sent over TLS. TLS encrypts the data in transit over the network
2. Know and understand what TLS cipher suites are being enabled on the server side to ensure no old and weak suite remain enabled unnecessarily
3. Use the POST method of http and send the password in the body to ensure the details do not linger in browser history or the webserver logs
4. Set the cache related headers appropriately to ensure the password is not cached in the browser or in the proxies
5. The password is not stored anywhere in the server or DB in clear text or encrypted form (except the hash using a password hashing algorithm like bcrypt). Note TLS only protects when the data is in transit
6. Once authenticated, as you mentioned, the JWT is used throughout the session and JWT does not contain password so it does not need encryption. If, however, JWT contains any confidential information, there is a separate specification JWE for encryption
7. Finally, the JWT needs to be stored in the client side appropriately to protect from XSS, CSRF attacks