Stateless Authentication (Token-based Authentication)
Token-based authentication enables users to obtain a token that allows them to access a service and/or fetch a specific resource, without using their username and password to authenticate every request. Because the token can be a self-contained entity that conveys all the required information for authenticating the request, then it is often referred to as stateless authentication. In this case, the server side does not need to maintain the state of a user.
The authentication token is created by the authenticating service and contains information to identify a particular user and the token validity. The token itself is cryptographically signed to prevent tampering.
After the token is validated by the service, it is used to establish security context for the client, so the service can make authorization decisions or audit activity for successive user requests.
Common standards for token-based authentication include JSON Web Tokens (JWT) and Security Assertion Markup Language (SAML).
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. The contents of the token can be digitally signed and consequently verified by the receiving party. Signatures can be applied using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA.
A stateless architecture is a software design concept where each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client and the client is responsible for storing and handling all application state related information on client side. It also means that the client is responsible for sending any state information to the server whenever it is needed.
To enable clients to access stateless APIs, it is necessary that servers include every piece of information that the client may need to create the state on its side. This includes also the specifics of authentication/authorization, which can be packaged as a token and sent to the server with every request.
In other words, in a stateless architecture, every request is self-contained and can happen in complete isolation from previous or future requests.
A stateless app is one that does not save client data generated in one session for use in the next session – instead session data is stored on the client and passed to the server as needed. Each session is carried out as if it was the first time and responses are not dependent upon data from a previous session. In contrast, a stateful application saves data about each client session and uses that data the next time the client makes a request.
For a protocol to be stateless, its communicating parties need to support a stateless architecture.
Token-based authentication enables users to obtain a token that allows them to access a service and/or fetch a specific resource, without using their username and password to authenticate every request. Because the token is a self-contained entity that conveys all the required information for authenticating the request, then it is often referred to as stateless authentication. The server side does not need to maintain the state of a user.
Token-based authentication can be used to enable a stateless architecture but can also be used in stateful architectures. For example, a JWT can contain all the necessary session data, encoded directly into the token, in which case it supports a stateless architecture. JWT can also be used to simply store a reference or ID for the session, in which case the session data needs to be stored server-side, making the architecture stateful.