JWT to Secure REST API with Spring Boot

October 27, 2017

JWT Working Flow

To Secure your Rest services and the way to handle users Authentication/Authorization, First Approach is sending basic HTTP auth headers (username/password) for every request, but that would require to keep those credentials in memory and the service would have to check those credentials .So this’s not the best way.

This is why REST services typically use a token system. A standard token system returns a 'token' (just a long unique string of random characters, for example a GUID) on successful login. The client in turn then sends this token in every request’s Authorization header. The service, on every request, 'rehydrates' its context by looking up the context on the server side. This context can be stored in a DB, retrieved from a Redis cache or simply stored in memory in a hash table. The downside of this approach is that for every REST method you will need to do this lookup in the database or cache.

And then comes JSON Web Tokens, or JWT in short. JSON Web Tokens are tokens that are not only unique to a user but also contain whatever information you need for that user, the so called claims. The most basic claim is the 'subject' (basically a unique user ID) but the tokens can be extended to include any information you want. Examples would be api access rights or user roles; you can simply add a 'roles' array with the 'user' and 'admin' rights to the claims when a user logs in. These claims can then be retrieved from the JWT whenever the client sends the JWT to the server.

Obviously this token is not just plain text; that would make it trivial for a client to add an 'admin' claim to it’s set. JWT’s are either encrypted with a secure key (only known to the server) or signed. The most common approach when you use JWTs is by signing them. This 'signed' bit of the JWT is called the JWS, JSON Web Signature. You use this approach when there is only information in the token that you want the client to be able to read. The base-64 encoded content is signed but not encrypted.

Another approach is by using JWE, JSON Web Encryption. With JSON Web Encryption you use an industry standard encryption method to encrypt the contents of your token. Only the server can create and decrypt the token so this means the client can’t read or alter the contents since it doesn’t know the secret.

When a user logs in with a correct password, he receives a token that looks like:

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJzaGFua2FyLnVtYTM1QGdtYWlsLmNvbSIsInJvbGVzIjoidXNlciIsImlhdCI6MTUwOTEwMTUxNX0.dKL8ZTOyrbFDM0uqpbgR2-fTRcL-2bIgrd4CsmyumYI

This 'token' is then used on subsequent API calls from the client to the server. The standard approach here is to send an Authorization header with a "Bearer" token. The header would thus be:

authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJzaGFua2FyLnVtYTM1QGdtYWlsLmNvbSIsInJvbGVzIjoidXNlciIsImlhdCI6MTUwOTEwMTUxNX0.dKL8ZTOyrbFDM0uqpbgR2-fTRcL-2bIgrd4CsmyumYI