The Secret Security Wiki

Categories

Home > Wikis > Network Architecture > Stateless Authentication

Categories

Stateless 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, 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).

Passwordless MFA ROI Calculator:

Find your ROI from adopting Passwordless Authentication

Passwordless MFA ROI Calculator

The Pros and Cons of Stateful Authentication

Stateful communication does come in handy for many of our online functions. There are instances where we would like our states to be remembered. When shopping online for example, after a user puts one item in his shopping cart, he doesn’t want it to disappear when he goes to another page to go choose another.

But stateful protocols do have their drawbacks as well.

Scalability:

The most obvious downside of stateful authentication is scalability. To keep track of session data, every individual session created needs to be maintained somewhere on the server. In a distributed system, even more server space is taken up as the session is shared between multiple nodes. When additional authentication servers are needed to support growth in services, users, or backups – those servers need to synced

Syncing the Cloud to On-Premise Identity:

Using a stateful authentication server means that identities now also reside in the cloud, and there are two identities managed by two directories; for example, one by Active Directory (on-premise) and one by AzureAD (Cloud).

The need to synchronize these identities can cause identity sprawl (AKA Directory Sprawl). Identity sprawl often arises when an application/system is not, or cannot be, integrated with the central directory service of the organization, resulting in the need to manage another set of user identities to support access to that application/system. Identity sprawl has been a problem for organizations adopting cloud services that operate a separate identity silo, which means users needed a separate identity for the cloud service.

The Security Factor

Because stateful communication stores login credentials, it runs the risk of those credentials being leaked, either through eavesdropping attacks such as Man in the Middle (MITM) or by a breach to the authentication server.

The Advantages of Stateless Authentication Cloud

Stateless authentication takes care of many of the downsides of stateful.

First off, stateless servers are infinitely easier to scale up, they are used as a gateway and do not store any credentials or identities making them easy to set up. They do not relay on synchronization with an on-premise identity provider (IDP) which removes the chance of identity sprawl.

Another advantage comes from a liability point of view, Stateful clouds contain sensitive (credentials and identities) information, which companies, especially in the financial and health care industry, would like to keep on premise, from a regulations point of view, stateless clouds are highly advantageous for compliance as the credential information never leaves the on premise server.

The use of purely on premise Identity Provider Servers is fading away with it the case for Stateless cloud servers is strengthen, choosing an authentication solution that harness stateless cloud architecture is not only a safer option it’s also a way to plan a head.

The Stateless, Passwordless Approach

When we designed our passwordless authentication solution, we designed it to bridge enterprises to the cloud, regardless to their current architecture our solution stateless authentication sever does not migrating identities to the cloud.

The combination of passwordless and stateless reduces the threats and costs associated with credentials while making sure identities are safely stored behind the security measures protecting the on premise IDP.

Learn more of Secret Double Octopus Passwordless Sing Sign On solution

  • What is a JSON Web Token?

    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.

  • What is a stateless architecture?

    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.

  • What is the difference between stateful and stateless cloud application?

    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.

  • Can any protocol be stateless (RestAPI, LDAP, SAML)?

    For a protocol to be stateless, its communicating parties need to support a stateless architecture.

  • What is stateless 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 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.

  • Is any token based authentication stateless?

    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.