- JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties.
- The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.
- For any application with restricted access, we must validate the requests without processing the client’s login credential in every request. To solve this problem, we have the JWT, which authenticates the users without cookies or login info.
- Authentication and authorization on RESTful APIs written with Spring Boot.
JWT in details
- The header contains all pertinent info to understand the token.
- The payload contains the claims.
- In short, the claims are the user’s data (or any entity) plus additional important information (not mandatory) that adds functionality to the token.
- We can find three types of claims: registered, public, private.
- Registered claims are used to provide additional information about the token, such as the time it was created or when the token expires. These claims are not mandatory.
- Public claims are defined by those who use JWT. One should be careful about which names they use since they can cause a collision.
- Private claims can be used to store information without using registered claims or public claims. Keep in mind that they are susceptible to collision.
- The signature is composed of the encoded header, encoded payload, a secret and the coding algorithm (also present in the header). And all that is signed.
- This is a rough look at the composition of a JWT.
Securing RESTful APIs with JWT
- JSON Web Tokens, commonly known as JWTs, are tokens that are used to authenticate users on applications.
- It enables backends to accept requests simply by validating the contents of these JWTS. That is, applications that use JWTS no longer have to hold cookies or other session data about their users. This characteristic facilitates scalability while keeping applications secure.
- During the authentication process, when a user successfully logs in using their credentials, a JSON Web Token is returned and must be saved locally (typically in local storage).
- Whenever the user wants to access a protected route or resource (an endpoint), the user agent must send the JWT, usually in the
Authorizationheader using the Bearer schema, along with the request.
- When a backend server receives a request with a JWT, the first thing to do is to validate the token. This consists of a series of steps, and if any of these fails then, the request must be rejected. The following list shows the validation steps needed:
- Check that the JWT is well-formed
- Check the signature
- Validate the standard claims
- Check the Client permissions (scopes)
Spring Security with JWT
- Spring Security’s default behavior is easy to use for a standard web application.
- It uses cookie-based authentication and sessions.
- Spring Security in the web tier (for UIs and HTTP back ends) is based on Servlet
Filters, so it is helpful to first look at the role of
- This filter will be used directly for user authentication. It’ll check for username and password parameters from URL and calls Spring’s authentication manager to verify them.
- If username and password are correct, then the filter will create a JWT token and returns it in HTTP Authorization header.
- The second filter handles all HTTP requests and checks if there is an Authorization header with the correct token. For example, if the token is not expired or if the signature key is correct.
- If the token is valid then the filter will add authentication data into Spring’s security context.
The configuration of the security using Spring Boot Security
- Password encoder – in our case bcrypt
- CORS configuration
- Authentication manager – UserDetailsService
- Set which endpoints are secure and which are publicly available
- Add our 2 filters into the security context
- Disable session management – we don’t need sessions so this will prevent the creation of session cookies