V3 Terminology Addition

[ryarmst]

I think it is necessary to provide definitions of terms used within V3 (and V1.3) and correlate to related and competing definitions. This is probably best added to the glossary when time to reorganize, but I would like to confirm terms for other V3 work. I added comments as indented bullets below items. Starting with the following:

• Stateful Mechanism or Token - These mechanisms utilize the application server to retain session state and token data in full.

• Stateless Mechanism or Token - These mechanisms encode information within the token(s) passed to clients that is not maintained by the server. A server may store some session information (such as a JWT revocation list) and be considered a stateless design.

  • This definition settles ongoing debate over what constitutes a Stateless session by simply defining a version where we permit some server-side state.

• Opaque Token - An opaque token is a token with no discernible structure or meaning outside of the issuing server.

  • Note: I have defined opaque above as it appears used across various industry players, but V3 appears to conflate opaque tokens (original use in #1478 (@tghosth)] with randomly generated stateful tokens. This use is not universal. For example, Auth0 defines them with "Tokens in a proprietary format typically contain some identifier to information in a server’s persistent storage" and I also came across Ory which uses a signature with "opaque" tokens. Some additional requirement rework may be appropriate for clarity.
  • I propose that a more clear and unconflicted term is used for this purpose (randomly generated stateful tokens). Please consider some candidate terms: Stateful Token, Server-Side Token, Random Token, Identifier Token, or just Randomly Generated Stateful Tokens.
  • Otherwise, I would suggest we simply adopt our own definition of Opaque Token as a randomly generated, high entropy string that is stored server-side to track sessions.

• Absolute Maximum Session Lifetime - Also referred to as "Overall Timeout" by NIST, this is the maximal amount of time a session can remain active following authentication regardless of user interaction. This is a component of session expiration.

• Inactivity Timeout - This is the length of time a session can remain active in the absence of user interaction with the application. This is a component of session expiration.

• Cryptographically Signed Token - These tokens often contain claims or assertions, relying on cryptographic techniques such as signatures or message authentication codes (MAC) to ensure authenticity and integrity of data encoded within the token structure.

Final note: it may be worth defining "Session ID" and "Session Token". These appear to be used interchangeably by documents such as OWASP Cheat Sheets. I think of "Session ID" as an identifier unique to a session whereas a "Session Token" is the actual string/data transmitted between client and server. They could be one in the same.

[elarlang]

Convince me that the "stateless session mechanism" is not an anti-pattern. It is a widespread source of problems that the access token "replaces" the session mechanism, but it does not and should not. I think it is important not to put fuel and support for the incorrect usage of stateless tokens and to point out the side effects. For this "rant" there is a separate issue (https://github.com/OWASP/ASVS/issues/1790) - I just pointed it out here to highlight the topic, but it should be discussed in the separate issue.

[ryarmst]

@elarlang I agree and #1790 is on my TODO list, but I want to have defined terminology first. The pattern is common enough that it is worth acknowledging, no?

[elarlang]

Acknowledging with discourage to keep using it :)

[jmanico]

Convince me that the "stateless session mechanism" is not an anti-pattern

I agree that over using access or identity tokens for sessions is an anti-pattern but there is nothing wrong with stateless session mechanisms as a whole catetogy.

In a high-traffic, multi-region microservice architecture, traditional session management relies on centralized session stores, which introduce latency and complexity. Stateless mechanisms like JWTs eliminate this bottleneck by allowing each service to validate tokens independently, improving performance and fault tolerance.

But you absolutely need to use them correctly. JWT’s and similar are new compared to traditional sessions and often are built without proper signature verification, revocation and other controls, but they scale way better than traditional sessions and are critical for microservice architectures where traditional sessions fall apart.

[tghosth]

@elarlang @jmanico I would rather not get into a discussion here of the relevant merits of stateless although we certainly need to highlight the security considerations.

Hi @ryarmst,

Based on your comments above and my own thoughts, I would say:

• Random Token - A random token is randomly generated by the application as a session identifier to be issued to clients to be able to maintain their stateful session.

• Cryptographically Signed Token - These tokens will generally contain claims or assertions, relying on cryptographic techniques such as signatures or message authentication codes (MAC) to ensure authenticity and integrity of data encoded within the token structure. The most common examples are SAML assertions and JWTs.

• Stateful Session Mechanism - A stateful mechanism utilizes the application to retain session state which corresponds to a random session identifier which is issued to the end user.

• Stateless Session Mechanism - A stateless mechanism will use a cryptographically signed token which is passed to clients, and contains session information that is not necessarily stored within the service which receives and validates the token. In reality, a service will need to have access to some session information (such as a JWT revocation list) in order to be able to enforce required security controls.

I think your descriptions of timeouts are great.

I agree with your definition of a session identifier and have tried to use that above. I would argue that in "stateless" system, there is no real session identifier.

[ryarmst]

@elarlang As far as terminology, what do you think about adopting "Stateless Session Mechanism" as above?

[elarlang]

@elarlang As far as terminology, what do you think about adopting "Stateless Session Mechanism" as above?

It describes how you can "make it work", but I'm not confident to call it stateless.

Always worth pointing to: http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/

ping @randomstuff

[tghosth]

@elarlang I think my description above acknowledges the fact that it is not truly stateless. I know people say it is a bad idea but practically speaking it is so widespread that it is almost an irrelevant discussion

[elarlang]

@elarlang I think my description above acknowledges the fact that it is not truly stateless.

This is an example of "stateless state" solution and I commented:

It describes how you can "make it work", but I'm not confident to call it stateless.

---

I know people say it is a bad idea but practically speaking it is so widespread that it is almost an irrelevant discussion

The more widespread the mistake is, the more relevant is to discuss it. ASVS must show the way to go, not following whatever way because it is so widespread.

[jmanico]

The debate between stateless and stateful sessions is often academic and unhelpful. Pure statelessness doesn't exist; all "stateless" solutions incorporate some form of tactical statefulness, such as databases, revocation lists, message buses, and more. Demanding pure statelessness ignores reality.

[randomstuff]

Pure statelessness doesn't exist; all "stateless" solutions incorporate some form of tactical statefulness, such as databases, revocation lists, message buses, and more.

… or public keys (which are rotated, revoked at some point) and current timestamp which are kind-of states as well :smile:

[tghosth]

I had a discussion with Elar about this.

I guess the question is, can we set out a set of conceptual security requirements for each area without getting bogged down into the details of what stateless or not.

So we would want to define a "Random Token" and a "Cryptographically Signed Token" but not get into definitions of "Stateful Session Mechanism" and "Stateless Session Mechanism" and the requirements would hopefully not need those definitions.

Does this sound achievable @ryarmst ?

[ryarmst]

I think the ASVS can definitely set out requirements independent of the stateful vs. stateless debate and this is generally the direction that I personally would prefer V3 to go in (I was going to separately propose rearranging sections based on random vs. crypto token use, though this will require further discussion related to other outstanding issues...), BUT considering the prevalence of "stateless" patterns and existing inconsistent use of terminology, my thinking is that providing terminology and potentially requirements around them would make the ASVS easier to use and more likely to result in better design, especially for the many (from my experience) teams that have adopted the stateless paradigm.

For example, here is a rough documentation (V1) requirement that could be used to steer apps into a stateful session pattern without preventing stateless patterns from meeting ASVS requirements:

Verify that, if user sessions are not managed using a stateful session mechanism, documentation includes justification for using a stateless session mechanism as well as implementation details for all necessary session controls.

[tghosth]

@ryarmst so my feeling is that I don't really want to steer apps to a particular pattern but rather I just want to state the security properties we need from a security mechanism. Maybe we could add a narrative note highlighting areas which might be difficult in a "stateless" mechanism.

Is that something you could draft?

[ryarmst]

@tghosth I'll drop that idea for now and suggest instead an update on V1.3 proposal text (#2103) to address mechanism pattern decisions.

[ryarmst]

Returning to the terminology, I would like to suggest the addition of the following items to Appendix A:

• Absolute Maximum Session Lifetime - Also referred to as "Overall Timeout" by NIST, this is the maximal amount of time a session can remain active following authentication regardless of user interaction. This is a component of session expiration.

• Inactivity Timeout - This is the length of time a session can remain active in the absence of user interaction with the application. This is a component of session expiration.

• Random Token - A random token is randomly generated by the application as a session identifier to be issued to clients as part of a stateful session mechanism.

• Cryptographically Signed Token - These tokens will generally contain claims or assertions, relying on cryptographic techniques such as signatures or message authentication codes (MAC) to ensure authenticity and integrity of data encoded within the token structure. The most common examples are SAML assertions and JWTs.

• Stateful Session Mechanism - A stateful mechanism utilizes the application to retain session state which typically corresponds to a random session identifier which is issued to the end user.

• Stateless Session Mechanism - A stateless mechanism will use a cryptographically signed token which is passed to clients, and contains session information that is not necessarily stored within the service which receives and validates the token. In reality, a service will need to have access to some session information (such as a JWT revocation list) in order to be able to enforce required security controls.

@tghosth I added the word typically to the stateful definition because I've seen crypto tokens used for this purpose as well.

[randomstuff]

Absolute Maximum Session Lifetime - Also referred to as "Overall Timeout" by NIST

Is our wording better than NIST's? Should we align with NIST? I quite like how "overall timeout" is consistent with "inactivity timeout".

Random Token - A random token is randomly generated by the application as a session identifier to be issued to clients as part of a stateful session mechanism.

That would be a random session token? You can have many different type of random tokens which are not session tokens (i.e. a Oauth state can be a random token, a PKCE code_verifier can be a random token, etc.).

Is the random session token necessarily a random session identifier or does not only need to be a random session verifier. I might have to have a session identifier whose knowledge does not grant access to the session.

Cryptographically Signed Token

OAuth talks about "self-encoded tokens". Should be align with this terminology or reference if as a synonym?

[ryarmst]

@randomstuff

Is our wording better than NIST's? Should we align with NIST? I quite like how "overall timeout" is consistent with "inactivity timeout".

Sorry, this was from another issue. Please see this comment from @elarlang.

That would be a random session token? You can have many different type of random tokens which are not session tokens (i.e. a Oauth state can be a random token, a PKCE code_verifier can be a random token, etc.).

Yes, thinking about this again, I think it makes sense to add Session to disambiguate.

OAuth talks about "self-encoded tokens". Should be align with this terminology or reference if as a synonym?

I think it may be worth referencing the term, but I think Cryptographically Signed Token captures a broader set of tokens. Based on my reading of the OAuth definition, self-encoded tokens are intended to encode all relevant info within the token. I have encountered tokens that are cryptographically signed, but not fully self-encoded.

[elarlang]

Should we align with NIST?

Our main goal is to be understandable. NIST does not provide easy reading so we are not searching alignment with wording there.

[tghosth]

Should we align with NIST?

Our main goal is to be understandable. NIST does not provide easy reading so we are not searching alignment with wording there.

Yeah I think "Absolute Maximum Session Lifetime" is fine here.

Yes, thinking about this again, I think it makes sense to add Session to disambiguate.

Agree, good point @randomstuff

I think it may be worth referencing the term, but I think Cryptographically Signed Token captures a broader set of tokens.

Agree, I can see the use of the phrase "self-encoded tokens" and also "self-contained tokens" but I don't think either are as clear as "Cryptographically Signed Token".

---

@ryarmst I think open a PR for the terminology. Is there anything else we need from this issue?

[ryarmst]

@tghosth PR opened. There is nothing more for now, but I think terminology (both definitions used and how they are referenced throughout) may be worth returning to again later.