[infopane color=”4″ icon=”0049.png”]This article is created by Oben ISIK. If you have any questions and reviews about this article please do not hesitate of sending an sms or email to me.[/infopane]
If we think about the meaning of authentication, it seems that, it is all about a client identify itself to the server. After client identification is done, the server can remember the client each time the request come from. There are two most common approaches to authentication mechanisms, one of them called “Session Cookie Based” and the other one is “Token Based”.
In this article, I want to focus on how to deal with automatic re-authentication of each HTTP and HTTPS requests.
What Is “Session Cookie Based Authentication” Mean?
In today’s world, especially for corporate businesses, most common usage of authentication is session based approach. In session based approcah, a session id -which is kind of a server generated token- is generated and stored in a cookie within the JSESSIONID paramter. This means server stores the session key in itself so when the server reboots or requests are redirected to another server by load balancers, your “state” of session key becomes useless.
What is “Stateless Authentication” Mean?
Whenever you are talking about REST API’s , API keys are mentioned too. Basically they involve sending custom tokens or custom keys within the HTTP Request header. There are several approaches such as OAUTH1, OAUTH2, Basic Authentication etc for implementing stateless authentication and today we will be focus on “Server Signed Token” approach that may be a life-saving for your implementations.
Server Signed Token Approach
First of all, it is easy to imagine that, in this approach; if server gets a request from the client, the client should send a token and the server should check and sign it before giving any response to the client.
With “Server Signed Tokens” a user identification data is shared with the server for authentication and when the server authenticate the user, it gives a hash key which is called “token” to the client. After this step, client can use this token to ask for any request to the server so the server should sign and approve that token is valid for request.
Let’s get into the details of the implementation of this approach.
The first step is authentication. In authentication step, client sends it’s user specific identification data to the server and if this data is correct server response a token to the client with HTTP 200 OK, if the data is uncorrect server response a HTTP 403 Forbidden.
After this approval is done, the client can send another requests without giving any user specific identification data to the server again again. Client only uses this token for further requests.
To understand all of the steps easily, it is good to have a scenario. For example, we want to make a login page with the inputs of username and password and after the user is logged in successfully, we want to show the user profile page with user information in it.
In Spring, we have WebSecurityConfigurerAdapters which helps to implement the security configurations of our spring project easily. In these adapters, there is a “configure” method for http securities.
In this configure method, we should add two filters which will be used in login step and the authentication step. (daha&helliip;)