Frontend authenticates in server using jwt token issued by another server

Question

I have two servers and frontend client:

1. one server authorize and authenticate user, after that issue jwt token to client.
2. Frontend client also visits second backend server using jwt token as Authorization Header.
3. JWT secret is the same on the both servers(encrypted by SH256).

Questions:

1. Is there any alternative to keep token safer and prevent steeling it by 3rd party javascripts? http-only cookie doesn't fit since client gets some data from jwt token
2. Do you see some security drawbacks in existing flow?

Answer 1

JWTs are inherently about stateless authentication. This means you can verify it's valid by checking a public key, authenticating the token is issued by the party the token claims it is.

In terms of stealing the JWT - yes, you can take this key and it will be valid everywhere. But the message contained in the JWT can change. This is where authorisation scopes come in - you can specify this token is only valid for this specific purpose. Stolen JWT can be kinda useless if the resource being accessed require more scopes.

You can also expire tokens. If stolen it will only be valid for a short time, limiting the damage.

Also, storing it on a user end point is fairly secure given cookies are only accessible by the site and not by some other site.

Google's Firebase is used exactly in the flow you describe. A third party is the auth provider, issuing a JWT. You check Google's public key to verify the JWT is indeed signed by Google and can use that as proof a user is authenticated for the scopes the token says they are.

Answer 2

An authorization token should be just that. That is, a big number.

The token itself should not include any data that your backend servers can decrypt. This isn't safe.

What one does to generate the token is use as random as possible data from their computer (such as /dev/random or /dev/urandom). This forms the token. This is as safe as can be over such transaction. The bigger the token the better. Transforming a randomly generated token using SHA256 (or any other similar hashing algorithm) is useless. There is no data attached to that token.

The random number is then saved in your database as the key of whatever data associated with the token. In your case that would be the user identifier. So something like this:

  Token  |   UID
---------+---------
123      |       5
456      |      12
...

There are papers out there about how long the random token should be. 4096 bits is a lot if the cookie lifetime is really short. Many people only use 256 bits. If you have a relatively small number of potential users, a smaller number will certainly work just fine. Here the decision may change the amount of data traveling on each request. Something to keep in mind, I think.

References:

• How many bytes should an authorization token have?
• How long should a random nonce be?