If you are interested in token-based authentication, then this blog is for you. In this blog, I mainly focus on token-based/stateless authentication and how to implement it using JWT (Json Web Token).
Stateless/token-based authentication
Stateless authentication means that on the server side, we do not maintain user state. The server has no idea who sent the request because we don't maintain state. We can achieve stateless authentication by using JWT (JSON Web Token). But before getting into JWT-based and token-based authentication, let's take a look at the past ways of using session cookies for authentication.
Status verification
How does this work?
The browser sends a POST request to the server, which contains the user's ID and password. The server responds with a cookie set on the user's browser, which contains a session ID used to identify the user. In each subsequent request, the server needs to find the session and deserialize it, because user data is stored on the server.
Disadvantages of state verification
Difficult to scale: The server needs to create a session for the user and persist it somewhere on the server. If we have a distributed system, we must ensure that the session is shared among multiple nodes.
Cross-domain resource sharing (CORS): When using AJAX calls to obtain resources from another domain ( cross-domain ), we may encounter the problem of prohibiting requests, because by default, HTTP requests do not include cookies in cross-domain requests.
Coupling with the web framework: When using server-based authentication, we will bind with the authentication scheme of our framework. Sharing session data between different web frameworks written in different programming languages is indeed very difficult, or even impossible.
Stateless/token-based authentication
In stateless authentication, there is no need to store user information in the session. We can easily use the same token to obtain secure resources from a domain other than the domain where we log in.
How does this work?
The browser or mobile client sends a request containing the user's login information to the authentication server. The authentication server generates a new JWT access token and returns it to the client. The client needs to store the token and send each request to the restricted resource in the Authorization header. Then, the server verifies the token, and if the token is valid, it returns the secure resource to the client.
Advantages of token-based authentication
Stateless and easy to extend: The token contains all the information that identifies the user, without the need for session state. If you use a load balancer, you can pass users to any server without having to be bound to the same server we log in.
Reusability : We can have many separate servers that run on multiple platforms and domains and reuse the same token to verify user identity. It is easy to build an application that shares permissions with another application.
Performance: There is no server-side lookup to find and deserialize each requested session. The only thing we need to do is to verify the token and parse its content.
What is a JSON web token?
JSON Web Token (JWT) is a compact and independent method for the secure transfer of information as JSON objects between parties. Since this information is digitally signed, it can be verified and trusted. You can use a secret (using the HMAC algorithm) or use the RSA public/private key pair to sign the JWT.
Compact : Due to its small size, JWT can be sent via URL, POST parameters or HTTP headers.
Self-contained : The payload contains the necessary information about the user, so we can reduce some database calls.
Structure of JSON Web Token
The JSON Web Token consists of three parts, which are separated by dots (.), which are
-
Header
-
Payload
-
signature
JSON web token example
|
1 |
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ0b3B0YWwuY29tIiwiZXhwIjoxNDI2NDIwODAwLCJodHRwOi8vdG9wdGFsLmNvbS9qd3RfY2xhaW1zL2lzX2FkbWluIjp0cnVlLCJjb21wYW55IjoiVG9wdGFsIiwiYXdlc29tZSI6dHJ1ZX0.yRQYnWzskCZUxPwaQupWkiUzKELZ49eM7oWxAQK_ZXw |
Header
The header usually consists of two parts: the type of token (ie JWT) and the hash algorithm used, such as HMAC SHA256 or RSA.
Payload (claim)
The second part of the token is the payload, which contains the claims. There are two main types of claims: reserved claims and private claims.
Reserved claims : These are a set of pre-defined claims, not mandatory, but recommended to provide a set of useful claims. Some of them are: iss (issuer), exp (expiration time), sub (subject), aud (audience), etc.
Private Statements : These are custom statements created to share information between parties.
The sample payload may be
|
1 2 3 4 5 6 7 8 9 |
{ "sub" : "sample_user", "Account" : { "userName" : "sample_user", "firstName" : "sample", "lastName" : "user", "emailId" : "[email protected]" } } |
signature
To create the signature part, you must obtain the encoded header, encoded payload, secret, the algorithm specified in the header, and sign it.
JWT security and encryption
If we want to put some sensitive information in the JWT token, in order to protect the sensitive information, we can use the JSON Web Encryption (JWE) specification to encrypt the JWT payload itself.