The Dev World – Sergio Lema

Choose the right authentication system without compromising the security and the user experience.

This may be a hard topic to handle on every project.

In this post I will list the main authentication systems and which one to choose depending on the application.

Let’s go.

Basic Authentication

The easiest one to implement is the basic authentication.

@Bean
public SecurityFilterChain filterChain(HttpSecurity http) {
	http
		// ...
		.httpBasic(withDefaults());
	return http.build();
}

$ curl localhost:8080/messages -u <username>:<password>
> ...
> Authorization: Basic dXNlcjpwYXNz
> ...

With the Basic Authentication, I must send the credentials (username and password) at each request in the headers. They are encoded in Base64 and added in the Authorization header.

The drawback is that the credentials can easily be decrypted if the requests are intercepted. Thus, as the header is sent at each request, the probability to be intercepted is higher.

When to use this authentication system?

It’s best used for API usage. When my application is used as an API from another backend.

When the requests are made individually, without any history, without any context.

From backend to backend. Individual requests, without context. As batch processes like upload a big file.

JWT (JSON Web Token)

The next step is to still use a value sent in each request header, but this time, which is hard to decrypt.

With the JWT, the token sent at each request can only be decrypted by the backend which created it. This makes the job harder when intercepting the token to decrypt it.

Another advantage of the using the JWT, is that the decrypted token doesn’t contain the credentials, but just some basic information (like the name, id and roles). This way, even if someone decrypted it, it won’t be very useful.

More advantages? I can even add a validity date. This makes my token invalid after 1 hour, 1 day or 1 week.

In comparison with the Basic Authentication, the credentials of the user are sent only at the first exchange with the backend. When the backend validates the credentials, it creates a JWT which is returned.
From there, the further requests will use the JWT instead of the raw credentials.

When to use the JWT instead of theBasic Authentication?

With the JWT, as the security is higher, I can use it in requests which have context, which have a history (not only individual requests).

To be Restful compliant, the context (the history of the user) must be sent in the body of each request. This means that it should be as small as possible. For bigger context, take a look at the Session in the next section.

The JWT is widely used for the exchange between a backend and a frontend.

Cookie Session

Instead of sending any information in the header, the Cookie Session sends a random token in the cookies.

As with the JWT, the Cookie is created when the user sends for the first time the credentials and after the backend validates them.

Then, all the exchanges are done with the Cookie. When the backend receives the Cookie, it looks for it in memory and retrieves all the user and context information.

The usage is very similar with the JWT.

When to use the Cookie Session?

When I need a more complexe context to be maintained between each request of a user.

Still, my application (the frontend) needs to accept the usage of Cookies.

The implementation of this system is done automatically if I’m using Spring Security. And I can store any information in the user’s Session (simple values or complexe objects).

The drawback is that the Session, by default, is saved in memory in the backend. This means that if the backend stops or restarts, the Session information will be lost.

To solve this situation, I have to implement a serialization process to save the Session information somewhere else (database or cache system).

As with the JWT, this is used for a communication between a frontend and a backend.

OAuth2

Until now, the authentication systems need that the backend verifies and validates the user’s credentials.

But sometimes, I don’t want to handle by myself the user’s information. I prefer to let another organization do it for me.

Using the OAuth2 authentication protocol, I delegate the task to authenticate a user to another server, to an authentication server. I may own this server or not.

This way, if my application is hacked, the user’s information won’t be compromised.

Thus, some users don’t want to create another account for my application. They prefer using their already existing accounts (as Google or Facebook) and don’t need to remember another password.

The usage of this authentication system is exactly the same as the JWT. For a communication from a backend and a frontend, when the context between the request is not big. But where I don’t (or don’t want to) handle the credentials of the users.

Conclusion

Here is a simple table where I list the features to easily choose the more adequate authentication system.

You can see more at this article.

If you want to learn more about good quality code, make sure to follow me on Youtube.