cleanup V3.5 Token-based Session Management

[elarlang]

Started to re-investigate issue #1790, then checked the section "V3.5 Token-based Session Management" and reached to the conclusion, that the entire section should be just cleaned up.

At the moment collecting first impressions as feedback. If needed, I split each topic into separate issues.

TLDR

• Requirements 3.5.3, 3.5.4, 3.5.5, and 3.5.6 are general token validation requirements, that are not limited to session context and should be moved to "V13 API and Web Service"
• Requirement 3.5.1 - it is not a session requirement, should belong to OAuth or be moved together with 3.5.7.
• Requirement 3.5.7 - it is not a session requirement, and should be moved to access control

3.5.1

#	Description	L1	L2	L3	CWE	NIST §
3.5.1	[GRAMMAR] Verify that the application allows users to revoke OAuth tokens that form trust relationships with linked applications.		✓	✓	290	7.1.2

Is it really a session management issue? Seems more like a business logical permission management - if a user has given permission for the application to access some 3rd party application on his/her behalf, then:

• 1. the application must provide the functionality to revoke those tokens
• 2. the 3rd party application must revoke them (but it's out of scope from the application point of view)

CWE is not helpful here.

Also, if it is OAuth specific, it should be moved there.

In case it is not OAuth specific, it should be considered as access control requirement and move together with 3.5.7.

3.5.3, 3.5.5

#	Description	L1	L2	L3	CWE	NIST §
3.5.3	[MODIFIED, LEVEL L2 > L1] Verify that stateless session tokens make use of a digital signature to protect against tampering and this is checked before processing it further.	✓	✓	✓	345
3.5.5	[ADDED] Verify that only allow-listed signing algorithms are allowed for a stateless token.	✓	✓	✓	757

3.5.3 should not be limited with "stateless session tokens", just "stateless tokens".

Not a session specific requirements.

3.5.4

#	Description	L1	L2	L3	CWE	NIST §
3.5.4	[ADDED] Verify that stateless tokens are checked for expiration before processing them further.	✓	✓	✓	613

So it should cover "time window" when the token is valid.

To check the expiration, we need to require exp to be present and set.

Not sure what security problem it takes down, but technically it should also cover to check nbf (Not Before).

Related RFC https://datatracker.ietf.org/doc/html/rfc7519

Not a session specific requirement.

3.5.6

#	Description	L1	L2	L3	CWE	NIST §
3.5.6	[ADDED] Verify that other, security-sensitive attributes of a stateless token are being verified. For example, in a JWT this may include issuer, subject, and audience.	✓	✓	✓	287

Not a session specific requirement.

3.5.7

#	Description	L1	L2	L3	CWE	NIST §
3.5.7	[ADDED] Verify that all active stateless tokens, which are being relied upon for access control decisions, are revoked when admins change the entitlements or roles of the user.	✓	✓	✓	613

The context here - first-party party tokens. It should be clarified in the requirement if we'll keep it.

Another problem - to have the requirement in the session category, it assumes, that stateless tokens are used as a replacement for stateful session.

As I wrote here: #1790 (comment)

From NIST SP 800-63B version 4 (not released) 7.1.2 Access Tokens:

An access token — such as found in OAuth — is used to allow an application to access a set of services on a subscriber’s behalf following an authentication event. The presence of an OAuth access token SHALL NOT be interpreted by the RP as presence of the subscriber, in the absence of other signals. The OAuth access token, and any associated refresh tokens, MAY be valid long after the authentication session has ended and the subscriber has left the application.

If we remove the session context from the requirement, it is still a valid requirement - but should be moved to the "V4 Access Control" category.

[tghosth]

3.5.1 - Agree it should be part of the OAuth Chapter
3.5.7 - Agree it can be moved to access control.

The rest, I would support some rewording of the requirements and the section name but I am not convinced about moving them to an entirely different chapter as people will mostly (admittedly not always) come across these tokens in a session management context.

[elarlang]

Let's try to get the first 2 sorted...

3.5.1

Thinking more about 3.5.1 - I think it is not the best fit for OAuth, although suits there better than in the session category, but maybe we should look at it as general access management logic, not as an OAuth protocol-specific requirement.

3.5.7

We don't have a matching requirement for the same situation in the "classical session management" - if the permissions for the user are changed, it must have immediate effect. Such as in case those are buffered to session data, those also must be "revoked".

So maybe we need to make this requirement to cover both situations and to be more abstract. Or do we need to have another requirement for "classical session management".

both

Till we don't have anything better, I propose moving them to the current V4.3 Other Access Control Considerations, or, if anyone has a good proposal, to a new section with the meaning "Access Control Management". Need to re-check when we going to re-work V4.

ping @tghosth

[tghosth]

Thinking more about 3.5.1 - I think it is not the best fit for OAuth, although suits there better than in the session category, but maybe we should look at it as general access management logic, not as an OAuth protocol-specific requirement.

I agree with the concept where access tokens have been issued and I agree with moving it to access control but you would need to reword it to make it a little clearer as to why.

So maybe we need to make this requirement to cover both situations and to be more abstract. Or do we need to have another requirement for "classical session management".

So the reason this exists is that in a stateless session, the session token might be relied upon for the permissions the user has whereas in stateful it will always be checked against the database. I agree that it could be combined into one requirement and made more abstract

[randomstuff]

Verify that stateless session tokens make use of a digital signature to protect against tampering and this is checked before processing it further.

To be strict this should be "digital signature or MAC": "Verify that stateless session tokens are protected against tampering (eg. using a digital signature or a MAC) and this protection is checked before processing it further."

[randomstuff]

Verify that all active stateless tokens, which are being relied upon for access control decisions, are revoked when admins change the entitlements or roles of the user.

We can't revoke the token if it is really stateless, though.

[jmanico]

This is not true. There are several revocation strategies first discussed here. https://datatracker.ietf.org/doc/html/rfc7009 And certain tokens like refresh token require revocation after users cancel that relationship and more.

A common strategy is to maintain a unique token ID or use redis/memcache to maintain temporary revoke lists.

And although this may mean by a strict definition the architecture is not completely stateless, these revocation strategies are still mostly stateless and not not require a full-on server-side sessions.

We can't revoke the token if it is really stateless, though.

[randomstuff]

A common strategy is to maintain a unique token ID or use redis/memcache to maintain temporary revoke lists.

Yes, my point was that it is not really stateless anymore. I believe some people want really-stateless stateless tokens and use short-lived access-tokens and that this should not be forbidden (?).

What about something such as: « Verify that changes in the entitlements or roles of the user are reflected in all active stateless tokens after at most {DURATION}. ».

If you have a short-lived stateless token which a duration of 1 minutes, it might be OK if role/entitlement change is not reflected on the RP before the next token refresh. Anyway, in many cases, you will have some delay because of caching and such. For example, if you use Status List.

[jmanico]

What is the use case for very short-lived tokens that last just a few minutes? I'm sincerely asking because I have not encountered that before.

[randomstuff]

I would say the use case for access tokens which last a few minutes is to have really stateless access tokens while providing short grant revocation propagation.

RFC6819 says:

tokens may expire after a few minutes (e.g., for payment transactions) or stay valid for hours (e.g., read access to contacts).

Some examples in the wild:

• Some Stack Overflow answer suggests that Rakuten access token is (was?) 5 minutes.
• Pro Santé Connect (OIDC) access token is 2 minutes.

[tghosth]

I think this issue is waiting for the V3 rework which I don't think has been assigned yet but the points will certainly be considered when it happens

[jmanico]

Before we move 3.5.7 I want to make a comment.

3.5.7	[ADDED] Verify that all active stateless tokens, which are being relied upon for access control decisions, are revoked when admins change the entitlements or roles of the user.	✓	✓	✓	613

Revoking the token when the admin entitlement is not the best strategy. Just like using REDIS for revocation, I can set a REDIS rule to over-ride the tokens access control with the new entitlement and not force a user to log in again, if this is used for session management. Token revocation here is a fairly weak and user-unfriendly method. So if we keep 3.5.7 I'd suggest:

3.5.7	[ADDED] Verify that all active stateless tokens, which are being relied upon for access control decisions, are revoked or overridden with the new access control entitlement when admins change the entitlements or roles of the user.	✓	✓	✓	613

[randomstuff]

And although this may mean by a strict definition the architecture is not completely stateless, these revocation strategies are still mostly stateless and not not require a full-on server-side sessions.

I think that "stateless" token should be stateless by definition 😉. If you don't intend to mean that the stateless token is stateless the name should be changed for something more precise.

[jmanico]

In real-world scenarios, systems frequently mix stateless and stateful design elements to find a good balance between security, performance, and scalability.

One of the common strategies is cache-based revocation so the performance impact is less:

1. Better Security: Revocation helps reduce the risk of compromised tokens being used until they expire.
2. Trade-offs: This approach adds some state management, which can impact scalability and performance, especially in systems that are spread out over many servers.
3. Implementation: Managing the cache efficiently, such as using distributed caches like Redis or Memcach (very common revocation strategies), can help reduce some of the performance issues.

[jmanico]

I suggest a change to 3.5.3 from:

3.5.3	[MODIFIED, LEVEL L2 > L1] Verify that stateless session tokens make use of a digital signature to protect against tampering and this is checked before processing it further.	✓	✓	✓	345

to

3.5.3	[MODIFIED, LEVEL L2 > L1] Verify that stateless tokens use a digital signature or HMAC to protect against tampering, ensuring it is checked before processing further..	✓	✓	✓	345

This accounts for the comments above as well.

[randomstuff]

"HMAC" should be replaced by "MAC": any other (non-broken) MAC could be used.

(Would it be useful, to mention authenticated encryption algorithms here?)

[randomstuff]

"before processing further" is somewhat vague/ambiguous.

[jmanico]

So how about:
How about this?

3.5.3	[MODIFIED, LEVEL L2 > L1] Verify that stateless tokens use a digital signature or MAC to protect against tampering, ensuring it is checked before performing any other actions based on the token's contents.	✓	✓	✓	345

It's a LOT more specific, but too much so?

[elarlang]

Each requirement has now a separate issue for discussion and not to be discussed here:

• 3.5.1 - will be moved/replaced to OAuth via V51 revokation for OAuth tokens #2111
• 3.5.2 - (already moved away)
• 3.5.3 - 3.5.3 update (stateless token signature or mac) #2184
• 3.5.4 - 3.5.4 - token time-window validation #2185
• 3.5.5 - update 3.5.5 #2204
• 3.5.6 - proposal/discussion: JWT - 3.5.6 rephrase it to describe the goal and/or split to different requirements based on different goals #1967
• 3.5.7 - will be moved/replaced to V4 via 4.1.7 - Real time access control decision making (ed note: initially became 4.1.6) #2059

---

The section name "Token-based Session Management" is just misleading (the same way as "Cookie-based Session Management"). Token or Cookie is just a technical solution, how the "state" is delivered to the server, it's nothing about the management.

Session is a logic on topic of technology. I think session paragraph should not contain sections for validating stateless tokens or cookie setup, as those are technical things to validate also without the session context. In case we move them away, the link/reference must be clear.

[TobiasAhnoff]

I agree, either there is a session and then it should meet session requirements in V3 or it can be regarded as an access token and should meet access token requirements (with the note that access tokens or OAuth does not replace sessions).

To "clean up V3.5" (this issue and also to address #1790) I suggest to:

• Delete V3.5 and create a new "Access token" section in V13 (or another chapter than V3)

• Remove/rewrite "stateless session" things that are left in V3 (to adjust to that V3.5 is gone/moved)

• Perhaps move Cookie section last in V3 (it is not a perfect fit for V3, but cookies are closely related to sessions, just as tokens a related to API access, so I think the cookie section can remain in V3)

Then add the following requirements to the new "Access token" section (in V13) where each requirement does not depend on token format, but for clarity and since JWTs are commonly used, examples are only given for JWTs. They are based on the RFCs https://www.rfc-editor.org/rfc/rfc7519 and https://www.rfc-editor.org/rfc/rfc8725.html

Below is an example of how this section could look like (each requirement have it´s own specific issue, some reference existing open V3 issues, while some are new)

V13.?? Access tokens

Regardless of token format the following requirements should be met to assert that the token is a valid access token. Examples are given for JWTs, but this applies to other token formats (like SAML) as well.

Requirements related to authorization decisions is part of V4 and OAuth related requirements are part of V51.
Note that access tokens (or OAuth) is not a replacement for the session management (which is part of V3).

Verify that access tokens are cryptographically secure, either by using a digital signature or MAC to protect against tampering. If validation fails, the token must be rejected. (see #2184)

Verify that, for integrity protected tokens, only strong algorithms from an allow list can be used to create and verify the token. For JWTs, e g use PS256 and assert that 'None' value is not allowed for the 'alg' claim. (see new issue #2360)

Verify that the cryptographic keys for tokens belong to the token issuer. If both symmetric (MAC) and asymmetric (digital signatures) algorithms needs to be supported, additional controls must prevent key confusion. For JWTs the 'iss' claim must be validated to be a preconfigured expected value. (see new issue #2361)

Verify that all key material is from a trusted source for each token issuer. For JWTs this is typically achieved by having a preconfigured JWKS URI for the given issuer. (see new issue #2362)

Verify that the token is an access token intended for the service (API). For JWTs this can be achieved by validating the claims 'aud' and 'typ'. If audience is present, it must be validated to match against an allow list for the given API. If the typ claim is present, it should be equal to 'at-jwt'. (see new issue #2363)

Verify that the token is valid based on current time and, if present, the token identifier. For JWTs the claims 'iat', 'nbf' and 'exp' should be verified for time based validation. The claim 'jti' should be validated to identify a specific token, in example to assert that the token is only used once. (see #2185)

[randomstuff]

Verify that the token is an access token intended for the service (API). For JWTs this can be achieved by validating the claims 'aud' and 'typ'. If audience is present, it must be validated to match against an allow list for the given API. If the typ claim is present, it should be equal to 'at-jwt'. (see new issue #2363)

In this formulation, I read:

Verify that the token is an access token [...]

i.e. we must (among other things) make sure that the token is indeed an access token. This is a valid requirement but is different from the one we are currently stating.

I think, this should be:

Verify that the access token is intended for the service (API). For JWTs this can be achieved by validating the claims 'aud' and 'typ'. If audience is present, it must be validated to match against an allow list for the given API. If the typ claim is present, it should be equal to 'at-jwt'. (see new issue #2363)

[randomstuff]

V13.?? Access tokens

What quite worries me is that some most of these requirements are actually valid for a wide range of token outside of access tokens. If we include them in an "access token" section, we would end up repeating them once for each type of token.

[randomstuff]

Verify that access tokens are cryptographically secure, either by using a digital signature or MAC to protect against tampering. If validation fails, the token must be rejected. (see #2184)

The access token can be an opaque random token which would not need to be cryptographically secure using a digital signature or a MAC. If the intent is to disallow this, this should probably be states more explicitly.

[TobiasAhnoff]

The access token can be an opaque random token which would not need to be cryptographically secure using a digital signature or a MAC. If the intent is to disallow this, this should probably be states more explicitly.

Correct, the intent was not to disallow this, an access token can (just as a session identifier) be just a secure random string (without involving OAuth introspection). Perhaps this will include all (I will also update #2184)

Verify that access tokens are cryptographically secure, either by using a digital signature or MAC to protect against tampering, or being a secure random string (hard to guess and with low collision risk). If validation fails, the token must be rejected. (see #2184)

[TobiasAhnoff]

What quite worries me is that some most of these requirements are actually valid for a wide range of token outside of access tokens. If we include them in an "access token" section, we would end up repeating them once for each type of token.

What kind of tokens are you thinking about? I´m thinking APIs should should only accept some sort of access token (or be part of an application that has sessions). Other kind of tokens: OIDC ID Tokens, OAuth Reference access tokens and OAuth Refresh tokens should be part of (V51). Is it overlap between this proposed section and V51 you are concerned about (also noted in #2363 (comment)) ? Or something else?

[elarlang]

This discussion is getting here not followable and messy.

The original goal was to clean-up 3.5 section. My recommendation to use this issue was in context that if there are more JWT specific issues, then we should put them into 3.5 first and then see do we have enough content for a separate section. Current access token discussion from this point of view is out of scope from this issue, although related.

Whatever is related with precise proposal for any recommended requirement, please have discussion in related opened issue - and if there not any yet, please open new one.

So I recommend to open a new issue for with a proposal of access token related section. But first we need to figure out, do we have enough content for a separate section.

[elarlang]

More feedback on the "Access token" proposal.

What problem we solve with this new proposed section? Taking into account how many potential duplication and confusion we create with that.

I like that we have abstract stateless token section. As already pointed out, access token may or may not use stateless token solution.

Even if access token is JWT token, then the main difference for the token type comes when the application already validates the token (expires, signature, issuer, aud etc). General validation is the same procedure for every kind of tokens. "Access token" from the "stateless token" is mostly only the payload, and this can be already really flow-specific, such as OAuth. I don't think we need layers like "stateless token" > "JWT" > "Access token" > "OAuth". I still think stateless token > OAuth is enough.

If it requires more discussion, we can have some video-call. At the moment for me the direction or idea behind is not understandable.

[elarlang]

Problems listed here initially have been solved.

The future of the entire section we can discuss here: #2384