Stateless and Stateful Architecture

Refers to the state of the application, that is, the condition or quality of it at a given time. In stateless authentication, there is no session or user stored, containing only static contents. This differs from stateful, which is dynamic content.

A stateless process is an isolated resource, which does not reference any other service or interaction with another system. It operates only in that part of the code, without bringing information from old transactions, as stateless authentication does not store this type of data; each operation is done from scratch.

Stateful authentication allows information to be used more than once and is executed based on the context of previous transactions. Therefore, in applications where it is necessary to wait for a response or preexisting data, whether present in another system or database, stateful is used.

Stateless Authentication

Stateless authentication consists of a strategy in which, after providing credentials, the user receives an access token in response. This token already contains all the information necessary to identify the user who generated it, without the need to continually consult the service that issued the token or a database.

This token is stored client-side (browser), so the server only has the ability to check the validity of the token by confirming that the payload and signature match.

Stateless Authentication JWT

JSON Web Token (JWT) are keys with standards established in RFC-7519, containing an entity in the form of declarations, which are independent, without the need to call the server to revalidate the token.

Are strings encoded in the base64 standard using a secret key, as in the example:

Advantages and Disadvantages

Advantages:

• Low server memory consumption.
• Excellent in terms of scalability.
• Ideal for distributed applications, such as APIs and microservices.
• Generation and distribution of the token in an isolated application, without dependence on third parties.
• Easy interpretation and validation of token user data.

Disadvantages:

• Difficulty in access control.
• It is not possible to revoke the token at any time easily.
• It can facilitate the entry of malicious third parties, if someone has access to the token.
• The session cannot be changed until the token expires.
• The JWT token is more complex and may become unnecessary in centralized applications, such as monoliths.

Stateful authentication

Commonly used in various applications, especially those that do not require as much scalability, the stateful session is created in the back-end of the application, and the session reference is sent back to the corresponding user. Each time the user makes a request, part of the application generates the token. From that moment on, with each new request, this token will be sent again to the application to revalidate access. In this model, if there is any change in user data, the token can be easily revoked.

These are opaque access tokens, that is, a simple string in a proprietary format that does not contain any identifier or user data relating to that token. The recipient needs to call the server that created the token to validate it.

Example token: 8c90e55a-e867-45d5-9e42-8fcbd9c30a74

This ID must be stored in a database with the user who owns the token.

Advantages and Disadvantages

Advantages:

• Centralized implementation logic.
• Simplified access management and control.
• Excellent for monoliths, MVC applications and internal processes.
• More secure against malicious third parties.

Disadvantages:

• There may be an overload in the API responsible for validating the token.
• Failure in terms of scalability.
• Greater difficulty in distributing authentication between microservices.
• In a distributed application, if the authentication service fails, all other services become unavailable.
• Greater implementation complexity.
• Greater difficulty in integrating with third-party systems.

When to use each approach?

When to use a JWT Token and Stateless Authentication

• When greater performance is needed without worrying about overloading an API.
• When there are several communications distributed between services.
• When it is necessary to identify which user is performing an action in the system in different services.
• When it is not intended to persist a user's data, only their initial registration.
• If it is necessary to generate external access to the service.
• If it is necessary to manipulate the data of whoever is performing a certain action with minimal impact on the system.

When to use an Opaque Token and Stateful Authentication

• If full access control of users of a system is necessary, mainly to define access hierarchy.
• In a centralized application, without distributed services and without communication with external services.

Final Considerations:

• In some places, such as "API stress", the term may be replaced with "API overhead" for clarity.
• The section on "JWT Token" could include a more detailed explanation of what the "declarations" mentioned in RFC-7519 are, if the target audience needs more context.
• In the section on stateful authentication, the phrase "one part of the application will generate the token" could be clarified by explaining which specific part of the application is responsible for this.