Authentication / Authorization [JWT]

End to end authorization + auth strategy used in my web application MyServers

Background

For a traditional session approach, the user would login and would be issued with a cookie (JSESSION or something like that) with a key. This key would then be mapped to a value on the backend. That way we can store stuff about the user and everytime they come back to us we would know who they are.

JWT aims to be stateless. The way it works is that the user first authenticates and then receives a token. This token contains some claims i.e username, role etc. However, what makes this token special is that only we (server) can issue it by signing it with a private key. Once we sign the token it’s your responsibility (client) to deal with it. This makes the backend stateless as unlike sessions, we dont need to keep any information about the client.

In the perfect world, we could issue the client (as a JSON response) with a token and they could store it in local storage and keep sending it back to us until it expires. However, this is prone to XSS. On the other hand, if we sent the token as a cookie, it is prone to CSRF.

1. Basic auth (username / pass) to endpoint -> /login
2. Respond with -> { token: json-token-content }
3. Store token in local storage OR cookie
4. Send token to any /auth endpoint to receive restricted content

So the following approaches are not good enough due to XSS & CSRF.

The approach I implement in my application is as follows:

Where did this authentication flow come from?

The basic idea follows the guideline of this post https://hasura.io/blog/best-practices-of-using-jwt-with-graphql/

An alternate way to achieve what we have is using https://stackoverflow.com/questions/28918519/does-securing-a-rest-application-with-a-jwt-and-basic-authentication-make-sense/28953341#28953341

Approach used

So firstly we try to keep the JWT token short lived (5/10min). This way if anyone malicious gets hold of a token, the time span is not long. If they want to get a new token, they must issue a refresh token.

At initial login, we provide a JWT token (short lived) + a refresh token (long lived). If someone gets hold of the refresh token then ur fucked because you can use the refresh token to get a new JWT token…

Here’s the approach:

1. User logs in to /login (Basic auth, user + pass)
2. Issued with access JWT token as response JSON. Also issued with a refresh token stored in a HTTP Only cookie. This can’t be read by the client (javascript)
3. Client does not store jwt access token in local storage. Instead stores it in memory (as a variable or something)
4. Everytime client refreshes the page (F5) then that token is lost in memory and a new token needs to be issued.
5. To issue a new token they visit /refreshToken endpoint. The server automatically detects the HTTP Only cookie from the user. It checks the value in the database and notices that it’s still valid. A new JWT access token is issued to the user.
6. Client goes through the same process, stores the token in memory etc..

This is unlikely to lead to XSS as we are not storing token in local storage. We are also not subject to CSRF attacks as the refresh token is stored in a HTTP only cookie which cannot be read directly by the client. The client redirects to /refreshtoken and is issued with a new JWT access token. This access token can only be read by a valid / good client due to CORS policies.

Backend:

1. How to deal with authentication + Step 1 & 2 above https://www.toptal.com/spring/spring-security-tutorial. This guy also talks about the same thing https://www.kindsonthegenius.com/spring-boot/jwtjson-web-token-with-springboot-step-by-step-tutorial-part-1/ and has a youtube channel which is helpful
2. A utility class called JwtUtilToken is required https://github.com/Yoh0xFF/java-spring-security-example/blob/master/src/main/java/io/example/configuration/security/JwtTokenUtil.java or https://drive.google.com/file/d/1Ki782Sldlpq_1wo-dUP70qvo-acRC97h/view – Don’t worry about the details of this class, it’s just a utility to validate and generate a token using client secrets
3. Consider rotating your secret key to generate a JWT token. In my application, a new key is generated everytime the application restarts. AES key generated using https://stackoverflow.com/questions/18228579/how-to-create-a-secure-random-aes-key-in-java
4. Store refresh token in database (hash it first incase db is compromised)

Frontend

THIS VIDEO EXPLAINS AND IMPLEMENTS IT PERFECTLY https://www.youtube.com/watch?v=nI8PYZNFtac&ab_channel=DaveGray

1. Store access token in a variable with getters and setters. In react this is fine as long as user doesnt refresh the page (token wont disappear). However, if they do, then simply request for a new one using the refresh token
2. This is made easier using axios request and response interceptors
3. Before a request is made, we send a Autorization Bearer token automatically
4. If a response is returned with 401 or 403, we intercept it before the user sees it, quickly refresh the token for them, update the jwt access token and resend the original request. It’s like they never noticed !
5. https://www.bezkoder.com/axios-interceptors-refresh-token/ and https://www.bezkoder.com/react-refresh-token/ helped alot

CORS

Ensure content is only read by permitted websites.

Basically, when we send cookies from client to server, both parties must agree to it. Client must have withCredentials=true in header and server must have @CrossOrigin(allowCredentials = “true”) annotation https://stackoverflow.com/questions/24687313/what-exactly-does-the-access-control-allow-credentials-header-do