JWT vs Session Authentication for SaaS Apps: Revocation, Multi-Tenancy and Enterprise SSO

For a SaaS product, JWT and session-based authentication will affect many parts of your application and how your company works. It will impact tenancy isolation, how quickly you can remove user access, SSO, how your application scales, your mobile clients, how your application interacts with APIs, and how your application is architected.

The dominant architecture for a SaaS product is dependent on pragmatism as much as it is on philosophical beliefs. Session-based authentication simplifies and centralizes control of access revocation. On the other hand, JWTs simplify the creation of distributed and autonomous clients and APIs. As a result, many products use a combination of the two.

Xcentric Services takes a different approach to authentication. If you're designing the authentication process as part of your larger SaaS architecture, Xcentric views authentication as part of application architecture. Xcentric offers end-to-end development services, from the front end to the back end, including services for cloud development and implementation.

Consider the following factors when comparing Xcentric to other Authentication providers.

It is important to appreciate that while session/access information may be provided by a valid JWT, that does not automatically grant a user access to a given tenant, project, invoice, or other administrative functions.

JWT vs Session Authentication: The Core Difference

JWT vs session authentication differs mainly in where authentication state lives. In the context of a SaaS app, JWTs and sessions can both be implemented successfully depending on aspects such as the required revocation methods, client app types, the topology of the API, the tenant model, and how an organization wants to integrate their identity domain. Servers that require session state may want to look into server-side sessions. A SaaS application with multiple, if not all, possible client apps may want to look into access tokens.

Let’s consider a case where an employee’s access is revoked by an administrator and the employee recently logged into the app. If we need to immediately revoke the employee’s access and the employee’s session is still stateful on the server, then we have satisfied the requirement. With an access token, state is likely still maintained on the client, and we would also need to implement a way to clear the state on the client.

For the purposes of designing a SaaS application, it is more effective to postpone consideration of token formats and concentrate on questions related to the lifecycle of the application. Consider the following questions: How quickly must access be removed for a given user? Is a user associated with only one tenant? Is an identity provider (IdP) provided by the customer? Are mobile applications being developed? Will the customer consume the organization’s API? Are there multiple services that validate requests? Is authorization influenced by the type or value of a role?

Xcentric has the capability to design and implement scalable SaaS applications. In addition, our full-stack development services include the design and implementation of APIs and microservices as well as Cloud deployment

JWT vs. Session Token: Which is Better for a SaaS App?

JWTs and Sessions have pros and cons for SaaS applications and other scenarios. There are many factors, such as the requirements for revoking access, types of clients, the architecture of the application, and requirements of an organization, to take into consideration when designing an application. If an application supports multiple clients and needs to integrate with different services, then using access tokens may be preferred.

Let’s look at a scenario where an employee administrator removes an employee, and we need to revoke the employee’s access to the application. In this situation, session state can be used to implement this. In the case of access tokens, the application would not revoke the token automatically and would need a different mechanism to do this.

Because of the nature of SaaS architecture, it’s more advantageous to consider things like access management before defining token structuring. Here are some of the things we’ll need to consider:

• How immediately do we need to remove access?

• Are users associated with multiple tenants?

• Is a customer’s UIDP expected?

• Will there be subsidiary apps (e.g. mobile apps)

• Will there be requests made to our API?

• Will there be multiple components validating access?

• Are there frequent changes to the roles a user is assigned?

Xcentric’s full stack development services include design and implementation of secure, scalable SaaS solutions, integration of back-end services via microservices and API, and deployment and hosting in the cloud. Additionally, our team has extensive experience in performing continuous integration and development from the MVP stage through to production.

Revocation of JWTs: Consequences of Signed Token Immutability and Intensionality

To revoke a JWT when a SaaS customer removes a user, the application must introduce server-controlled state or wait for token expiry; a signed JWT cannot normally be edited or remotely recalled by its issuer after issuance. The default behavior of a signed token is that access control remains in effect until the token expires. Signed tokens cannot be edited, recalled or revoked. The application developer has to implement additional mechanisms to achieve token revocation. Examples of such mechanisms include: introducing state on the server; using token expirations to control access, implement a refresh token strategy; or denylisting the JWT.

The above behavior of JWTs is essentially immutable and is one of the design trade-offs of JWTs.

{

"sub": "user_4821",

"tenant_id": "tenant_91",

"role": "member",

"exp": 1780000000

}

The customer admin can remove access for that user, and the token will remain valid until it expires. The resource server would need to check some other revocation state to determine access should be denied.

OWASP suggests several other methods in addition to denylisting for dealing with JWTs. These include token status lists, using shorter token expirations, and token constraints. The guidance indicates the best solution depends on the use case.

Token constraint for refresh tokens is discussed in the IETF RFC 9700 from January 2025. In the RFC, token constraint is recommended for use with public clients and refresh tokens. In token constraint, the server limits how long a refresh token can be used. The server replaces the refresh token and invalidates the previous token.

The following table presents the off-boarding events and corresponding approaches to address the events. The approaches may use JWTs to support off-boarding or address other events.

Other events may require other approaches or integrations. For example, revoking a grant and/or other credentials may be required when there is a security incident. Assuming the role of a user changed, the server may also see the new role of the user. However, the server may not rely on stale claims when making authorization decisions.

Multi-tenant Authentication: Multi-tenant SaaS Authentication

For a multi-tenant SaaS, a user is identified, and the tenant context is set during authentication. Authorization requires an additional check to confirm the user is allowed to access the tenant and resource. In some cases, a tenant ID is included in the JWT. However, a tenant ID in a JWT should not be relied on to make an authorization decision. In most cases, authorization decisions are made on the server.

The design and implementation of a multi-tenant authentication solution may view tenant context as an authentication boundary.

An example of tenant context may look like the following:

"user_4821"

"tenant_91"

"api.example.com"

"invoices:read"

The API needs to verify that user_4821 is a user in tenant_91, that tenant_91 is an active tenant, the invoice is issued to tenant_91, and the user can read invoices.

In OWASP's JWT resource, it mentions that claims, such as iss, aud, sub, roles and groups, may contain information that impacts the security of the system, and states that relying on the JWT issuer and audience may provide a greater level of assurance. In a multi-tenant system, OWASP states that the system should resolve the verification key of the issuer that it trusts.

The system may take a different approach to the level of assurance, based on the trust level of the identity providers of the tenants.

For a SaaS product, this is where the design of the product’s database plays an important role. As an example, tenant isolation must be enforced throughout the process of authentication, authorization, and querying, and throughout the engagement of the product’s services, background jobs, and APIs.

Enterprise SSO: Enterprise SSO SAML OIDC SaaS

Enterprise SSO helps a SaaS application integrate with a customer’s IDP to authenticate and/or sign sessions using the SaaS application. SAML is a prominent standard for enterprise integration using the browser. OIDC utilizes JWTs as ID tokens and extends the identity layer over OAuth 2.0.

This point addresses the integration of Enterprise SSO and the SaaS application, as well as the JWT versus session consideration. The flow of an SSO is as follows:

• A user accesses the SaaS product

• The product extracts the user’s tenant

• The tenant defines its SAML or OIDC identity provider

• The user is directed to the identity provider for authentication

• SaaS product validates the SAML or OIDC assertion

• The product identifies and isolates the user at the tenant level

• The product issues session or access tokens to the user

SAML 2.0 and the Web Browser SSO Profile define methods for including single sign-on (SSO) for web applications within a larger framework for exchanging security information between business partners.

Compared to SAML, OpenID Connect is more of a layer built on top of OAuth 2.0 for providing a user's identity and an assertion to an authentication service.

An important architectural consideration is that a user's session in your enterprise IDP will not be the same session as a user's session in your SaaS product. It is correct to assume that your IDP will not set the session for the SaaS product. As such, your SaaS product should define and implement its own session management procedures after successful SSO.

SAML 2.0 specifies a method for exchanging security data between partner organizations, and defines a profile for web browser single sign-on (SSO).

Session vs Token Authentication for Mobile Apps and Public APIs

Session management, as compared to token management, becomes important when a SaaS product has Mobile App Development Company or APIs. Depending on the platform, APIs can communicate securely using session cookies or OAuth 2.0 access tokens.

Similarly, it is up to the service provider to implement session management. OAuth 2.0 and related integrated services cannot replace server-side sessions.

It is perfectly acceptable for a SaaS product to use different authorization methods and mechanisms for users and services. For example, it is perfectly reasonable to use sessions for users, access tokens for services, and other authorization methods and mechanisms for other service integrations.

Session vs Token Authentication for Mobile Apps and Public APIs

• OAuth access tokens for API consumers

• OIDC for customer SSO

• Refresh tokens for supported client types

• Separate authorization policies for human users and machine clients

For mobile clients, OAuth guidance by the IETF suggests public clients cannot secure their client secrets and thus should not use the client credentials grant type. Refresh tokens should not be used with public clients as outlined in RFC 9700. Instead, the use of sender-constrained refresh tokens should be implemented or refresh token rotations should be performed to guard against refresh token replay attacks.

What Location Should a SaaS App Use to Store User Session Tokens in the Browser?

For web (SaaS) applications, it is recommended by the OWASP and NIST that session tokens be stored securely by the web server, using, e.g. HttpOnly cookies, and not by the client (in LocalStorage or SessionStorage).

Cookies, by their nature, pose a CSRF threat. If cookie-based sessions are implemented, CSRF and other threats should be taken into account in the application’s request model, and the cookie should be configured with appropriate SameSite and Secure attributes.

OWASP states that session tokens, JWTs and other comparable tokens should not be stored in the client (in LocalStorage or SessionStorage). LocalStorage and SessionStorage should not be used to store authentication tokens.

In the case of a browser SaaS application, both cross site scripting and CSRF attacks must be accounted for. Therefore, relying on a single storage mechanism will not ensure adequate security.

Mobile apps tend to use OAuth 2.0 in accordance with the IETF guidance. One reason for this is that public apps cannot safely keep a secret. Therefore, in a mobile context, the IETF guidance tends to focus on OAuth 2.0. RFC 9700 states that if a public client uses refresh tokens, the tokens should be of the sender-constrained type, or refresh token rotation should be implemented to detect replay attacks.

HTTPOnly Cookie vs LocalStorage JWT: Where Should a SaaS App Store Tokens in the Browser?

For web-based SaaS apps, various agencies and organizations recommend a secure cookie or a Back-End-for-Front-End architecture over using HTML local storage for authentication. NIST specifically recommends a similar secure cookie approach over HTML5 local storage for session secrets. This makes the HttpOnly cookie vs localStorage JWT discussion less about preference and more about exposure.

Restricting session cookies to HTTPS and setting cookies to HttpOnly reduces the risk of user credentials being stolen. NIST also states the same. The cookie should also be configured with the SameSite attribute based on the application’s request model.

OWASP also states the same in their session management cheat sheet; authentication tokens should also not be stored in HTML local storage. Cookie-based session management also addresses CSRF.

Therefore, a browser SaaS application should account for both XSS and CSRF, and not rely on a single storage mechanism to secure the application.

Stateless vs Stateful Authentication and SaaS Authentication Best Practices

Stateless authentication reduces the need for centralized state during access-token verification, while stateful authentication keeps more lifecycle information on the server; SaaS authentication best practices generally prioritize explicit lifecycle control over achieving statelessness for its own sake.

From a design perspective, systems should strive for a fully stateless architecture. In practice, this means that every component can validate an authentication token without consulting a centralized state component. However, there will be cases where the component should operate statefully, e.g. if the user must be immediately blocked from all services provided by the business.

OWASP acknowledges this compromise in their JWT documentation. To maintain a stateless system, they recommend the use of a denylist to invalidate JWTs used for user sessions. Among other controls, SaaS systems should provide means to control the lifecycle of user access tokens and to suspend user accounts.

NIST's 2025 version of SP 800-63B also addresses session management as a discrete security area, and recommends a maximum session duration and restricted airport security-style reauthentication.

The Hybrid Pattern: Refresh Token Rotation for SaaS

A similar approach for SaaS systems is to use a fully stateful architecture for most components and integrations, and to introduce statefulness for components requiring revocation, e.g. using refresh tokens.

How access tokens are issued varies by client type, but in all cases, it is important to understand that an access token should contain only the information necessary to authorize the requested access.

The most recent IETF guidance pertaining to browser apps is relevant here as well. RFC 10017 states that browser apps using OAuth must Rotate Refresh tokens or use sender constrained Refresh tokens, and also must have a binding refresh token lifetime. The refresh token must also be configured to expire after a period of inactivity.

This architecture is flexible enough to address authorization and access needs across a wide variety of access and integration scenarios.

For Xcentric Services, the work done in authentication design directly informs the back-end development work done by the team. The company is a full-stack service provider and integrates backend solutions for Authentication, APIs and Microservices, as well as databases and other cloud services.

JWT vs OAuth: Are They Alternatives?

Although both standards address the issue of securing protected resources, JWT and OAuth are not alternatives to each other. The JWT standard merely defines a format for a particular class of tokens, while OAuth 2.0 defines a framework for authorization and token issuance. In combination with OAuth, the OpenID Connect standard provides a means for issuance and verification of tokens in authentication contexts. This distinction resolves much of the confusion around JWT vs OAuth.

Finally, it is important to note that a given access token issued by an OAuth provider need not be a JWT.

User authentication typically involves a variety of components. ID tokens, which are used to assert information about authenticated users, are a major element of the OIDC framework. However, ID tokens are distinct from the access tokens used to assert authorization to protected resources.

When building a SaaS application, the various layers can be thought of independently.