Unify terminology: Session Token vs Session Identifier #2924
Comments
tghosth
added
1) Discussion ongoing
|
Context: session reference token.
"identifiers or tokens" > tokens?
"session identifiers" context "session reference token"
Context: "session tokens" (although in practice it means "session reference tokens") |
Should say: "... to a random reference token which is issued to the end user."
yep
" for securing session tokens"
"session tokens" |
I think this needs some further work, "random reference token" and "reference token with pseudo-random value"? |
|
Maybe better to make it clearer and consistent with 7.2.3 and say:
|
elarlang
added
the
5) awaiting PR
elarlang
added
6) PR awaiting review
and removed
5) awaiting PR
|
Session token implies JWT, session identifier is more accurate for server side sessions, which are still quite common. |
Practically speaking, we call both types a token now, see the glossary:
|
|
I think this adds a lot of confusion. For decades we have called the reference to a server side session a "session ID" or "session identifier". And session tokens in most literature refers to JWT's. To call both a token is a bit off from the literature out there now. Why are you going in this direction, what am I missing? |
A while ago we agreed on the terminology here: #2924 (comment) One of the outcomes of this was to clarify that tokens can be reference (unique/random) or self-contained like a JWT but either way they are tokens. Practically speaking and right or wrong, the phrase session identifiers, session IDs or session tokens seem to be used interchangeably. I felt it was important we settled on one to avoid any idea that we are differentiating between them. |
|
Those terms have been through looooooong discussion involving many people, and if there is no clear mistake to solve, I prefer to not touch it. For all the reasoning should be investigated first from the previous issues before pushing changes into them.
For decades we have also used terms like XSS or CSRF, that are.. outdated. So it is not a good argument on its own. Session ID can also be a bit outdated - ID may be associated with numeric value, identifier is also not correct, because reference token value can be at the same time JWT of whatever. It is just a reference to server-side session information. The meaning of token is more general than JWT and also covers the usage of opaque values. Definitions from the Glossary as they stand:
|
|
Even thought we disagree on this Elar and Josh, I think you are both being reasonable. Let me do a little research on how other standards address this issue and I’ll get back to you.
|
|
I'm sure I'm missing some of the backstory here, but can I suggest to unify under "session reference" (since both offer a way to refer to sessions, whether on the server, client, or ephemeral), and use specifically ID or token when we need to disambiguate and talk about a particular one? |
|
As I wrote before, those terms went through battles here and are not for "let's start this discussion again"
It is not clear to me what problem this proposal should solve. "Session reference" is quite the opposite of the meaning of "self-contained token," which does not need to reference anything. A good material for reading: https://medium.com/@iamprovidence/token-gang-bearer-token-reference-token-opaque-token-self-contained-token-jwt-access-token-6e0191093cd0 Previously discussed in issue: #2414, before that in #2100 In short, we don't search for alternatives to the current ones, but if there is a mistake to solve, we can always review things. |
|
Ok, I understood from where those recommendations may be initiated. https://x.com/manicode/status/1910440798384251355
It is not really what I said here: #2924 (comment) Reaching the community is good, sending conflicting messages is not. |
I agree with you, Avi. I think using token for server side session it way too confusing. If you look at RFC 6265 (HTTP State Management Mechanism — defines Set-Cookie semantics) and many textbooks and academic literature (e.g., “Web Application Security” by Stuttard & Pinto) they also agree with you. Using session token to refer to a server side session is very confusing, IMO. |
We are not even at rc1 yet. As we release rc1 we are all going to need to be ready to have these discussions again, especially when someone as senior and sharp as Avi cares to donate his time to give his opinion. This is an open community standard that •no one• is in charge of. We work on this collectively as a community. |
I was absolutely and respectfully trying to represent this entire thread in a balanced way to get others opinion. And I referred to the issue so folks can read for themselves. If you have suggestions for a different tweet or similar let me know. There was nothing malicious intended with my tweet nor was in any way trying to misrepresent anything we are tying to do here. |
|
In addition to the response in #2924 (comment). Let me try one more, and hopefully last time - session identifier or ID, is typically an opaque or "pseudo-random" value that references some session state on the application backend. Is the data is stored in a file or in a database does not matter. It is fair to say that the session ID/identifier is always a reference value/token. At the same time, this reference value/token can be something else than "identifier" - some kind of token with checksum or whatever. So we are not limited to being an identifier, but we are always with reference. You may find session identifiers also inside self-contained tokens. For example, classical access token and refresh token from Keycloak contain a "sid" as one parameter/claim - that is session identifier inside a self-contained token. So, a reference token may be something else than just an "identifier", and a self-contained token may contain an "identifier". The purpose of this change is to divide the session mechanism into:
It may require some adjustments in your brain for 1-2 seconds to think about it like that. I really can not see any reason or possibility to revert that to back to vague "identifiers" that do not define or explain anything other than "it is some kind of id". If this was not enough, I recommend reading the article and the issue with discussions linked in previous comments. |
I'm not sure it got addressed well. 7.2.3 as it stands
@tghosth - I think we need to clarify this requirement "Verify that if opaque reference tokens ..." |
|
Elar, if you look at my twitter thread you'll see the first post agrees with you. And above, I stated that I think you are reasonable. I totally understand where you are coming from. And while I disagree, I am not trying to attack you or be disrespectful. Take a look at the OAuth draft on single page apps last published March 3, 2025. Section 6.1.2.3. Cookie-based Session Management states: "Server-side sessions expose only a session identifier and keep all data on the server" Also take a look at RFC rfc6265bis last published March 17 2025. This is the core standard for HTTP State Management Mechanism. They have a formal section that defines what a "session identifier" is. https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis#name-session-identifiers So the point I am trying to make is that the term "session identifier" is the core term used to describe server side sessions in formal IETF drafts as well as the core HTTP state management RFC each that were last published a few weeks ago. And while the term “reference token” is now common in the OAuth and OpenID Connect communities, no single RFC explicitly defines the phrase “reference token” as a formal term. And last, "reference token" is very specific to OAuth2 (delegation) and OIDC (federation) and is not a term typically used to describe general session management, while the term "session identifier" is, not just by my opinion, but in formal RFC's that are actively under development by the IETF and W3C. The term "reference token" is not, at all, being used in formal standards. So you can insult my brain all you want, but I suggest you give these other RFC's a read and show me even once where "reference token" is used in a formal standard. |
Both mentioned RFC drafts I have worked through (not just quick-reading) and sent my feedback (tens of points) to both of them. "OAuth 2.0 for Browser-Based Applications" is fresh content and describes precisely the situation and the context where "session identifier" is used. Although, "reference to server-side session" could be good as well. With rfc6265bis, you can state it was last published just in less than a month ago, but a lot of content has just been taken over from the rfc6265 released in 2011, and precisely your referred texts are not modified for the new version. There are many things to improve and some clear mistakes in this document. I have sent my feedback a few weeks ago to them. But this was just validating sources and claims "published just weeks ago". I can take the point that "reference token" is not widely used, and this is a concern I have taken into account when supporting our current direction. When someone is talking about session identifiers, they are talking about the type of content for the reference token. We defined session mechanisms - is it done through the reference token or is it done by a self-contained token. |
|
Collection of Jim's quotes:
Just my assumption here is that "old habits die hard"
Can this be the actual reason, Jim? |
Not at all. Here is my reasoning.
So you are going against the OIDC standard, the OAuth2 standard, NIST-800-63, the HTTP Statement Management RFC and many others. So this is not about me personally or my old habits. This is about every other standard on the planet that talks about these issues and I would like to be in alignment with them. |
|
And I would like to note something about the nature of how we are both debating.
I'll just leave that on the table for others to consider. |
|
Don't get me started about how we are "debating". You just quoted me back things which I just clarified to not be true. You don't read what is written before, why some decision are made as they are made and pushing just one agenda. That is why I don't see the reason to describe again line by line where[+] you do mistakes or are incorrect (first 3 are wrong claims, 4th is your opinion, and for 5th I agree - but probably if I go back to issues in the past, I can find you said something opposite). I have described the rationale the best I can, if this is not enough for you, then let it be that way. If I describe that we use name X for "the box of the apples" (reference token) then you are arguing "but the apple name must be Y" (session identifier). Those are different things (mechanism vs one type of the value) and can not ever find agreement. |
|
I absolutely read all of your suggestion and even stated you were being reasonable. See comment 2795169555 I think it's a very important point that there is no standard ever used the term "reference token" and cited many recent standards that use "session id or identifier" and you are completely ignoring my points and continue to make this personal. This is not personal. You logic is sound, Elar. It's just very different than all existing standard body conventions and that is a very reasonable concern I am bringing up. Conflating the term "token" is also a solid concern. So I don't know what more I can do to explain my very reasonable position. I am not making this personal, Elar, you are. I am citing standards while you attack the quality of my brain. So be it. |
I read it all carefully. I am not pushing an agenda, I have no agenda. I am citing many many standards that use the term session Id that were recently authored. That is not an agenda, it's facts of previous and recent publications.
People change their minds, there is nothing wrong with that. Things evolve, and so does my opinion. This is the most recent one, so instead of going back in time and trying to make a fool of me once again, why don't you address the recent standards I am citing?
It's a reasonable rationale, it's just completely against all current convention and is a confusing change for some. Just not me, but for others too.
A session identifier is a type of reference token. A reference token is a type of session Id. You can logically look at this both ways. I can see it both ways, your logic is sound. If I can find even ONE standard that uses these terms that you prefer, I'd be more likely to change my mind, but I cannot find even one standard that uses your terms. That's sound logic, regardless of how you choose to attack my opinions once again. |
|
Ok then...
Maybe, maybe not. If you had read my comment here #2924 (comment), you should not claim again about "recent standards". If you had read previous discussions, you could not say that it is "my term", because it was not even proposed by me. So, I have reason to doubt.
In #2924 (comment) I explained potential reasons why our proposed terms may be new and need adoption. Yes, based on quotes from you, but there was no personal attack. This is a general concern with a question - is this the case or influence on the situation at the moment.
It is important to point out that "reference token" is pointed out in OAuth-related RFCs, but the context is not user-session as such. Mechanism is the same. This is a concern, I agree. It was also in our discussion. Despite all that, this was the way chosen. Also, there is no standard for a session. It is just logical thing on top of web technologies and everyone can build their own solution, call the session nonce, id, token, or whatever. Claim about "we are against NIST" - we are not using a lot of things from NIST in the authentication chapter. I may ask why you don't push for "memorized secrets" instead of "passwords". I take it as a fabricated claim to show me "against standards".
The standards you are citing. Let me try as well. Standard 1) "OAuth 2.0 for Browser-Based Applications"
Yes, the term is used there. Once. As I commented before, it suits to use "reference to the session on the server side", but this is not their main context. Standard 2) "Cookies: HTTP State Management Mechanism"
If you are quoting this as the main reason, why don't you use the first option "nonce"? Just to show "selective" citing. Then the main claim, that it is recent - the draft is updated in March 2025, but this text is taken from the old version and is not updated. So it is not new content created recently, it is leftover from 2011.
Let's see. But it does not happen fast. Important to point out, those are not "my terms", not even initially proposed by me. But agreed by me, including others. Read the related issues. We don't go for new terms easily. But if there is a clear reason to do so, we don't avoid it just because no one has done it before. But the terms were not invented by us, for example read the article. You can point me to plenty of RFCs that mention "CSRF" or "XSS", but that does not mean there is an actual valid reason to use those terms. |
|
Hi folks. I feel like you have all gone down a rabbit hole, and are spending a lot of time debating this topic, when instead you could all be doing the extremely important work of creating and improving ASVS. Jim has pointed out repeatedly that he's using the same words that RFCs use for what's being described, and I don't see why you can't use that term. Elar, although your description/term is not bad at all (I absolutely get what you mean, it is clear), I don't understand the passion around this proposed change/edit of this term. It seems like a lot of energy, and I'm not sure where this is coming from. I'm not sure how it's adding value to ASVS to debate at this level. Tanya perspective: when I teach I say 'session token' to refer to what is passed back and forth to continue to identify the active session. The value that is inside, I call a 'session id'. Now you've both made me question that. Lots to think about from this long thread for me. Good luck, to all of you. This exact thread is why I don't volunteer for projects like this. You all have more patience than I do. I thank all of you for the work you do on this and other OWASP projects. |
|
Thanks for the ongoing exchange, @elarlang . I want to close out my perspective with clarity, evidence, and respect for your logic — even if I disagree with the direction. My position is not about nostalgia or stubbornness. It is rooted in the fact that the term "session identifier" is consistently and formally defined across many standards and publications:
In contrast, "reference token" does not appear in formal session management contexts in any RFC or NIST publication, and is specific to OAuth/OIDC delegation workflows. It’s simply not a widely adopted or recognized term outside of that niche. I respect your desire to bring clarity and differentiation to the taxonomy, and you’ve explained it well. But I worry that this change will:
Let’s keep making ASVS as accessible and authoritative as possible — which means aligning with how the security community, including standards bodies, are already communicating. I won’t comment further unless specifically asked, as I don’t want to derail progress. Thanks again for the thoughtful debate and your time. PS: Despite the brain jabs, I still think you’re a thoughtful contributor, @elarlang . We all want the same thing — a great standard. I’ll let this rest here. |
|
Surely Session identification is implied by the presence of a session token, the token is just the vehicle that carries it. Are we overegging this custard ? |
|
I would recommend maintaining the use of “session identifier” for server-side sessions (traditional session cookies) and preserving “session token” for self-contained tokens like JWTs. This approach preserves clarity and aligns with established terminology in security standards. |
|
So, instead of reading what I wrote about "official standards", Jim is repeating exactly the same phrases that I proved to be incorrect or questionable (at least) twice. That is why I can not call debates or argumentation, because lack of arguments does not stop it anyway. Instead, "let's find my friends who support my idea and win the argument". Nice job. To all who got an invitation here - thank you for your feedback. Some of you questioned the rationale and reasoning for it, which is a valid and good question. There are long stories behind this thread. I hope you put the time behind the rationale of proposed changes, it is beyond this issue and has been through long discussion. Although served like this by Jim, it is not asking "if you have a session token and session identifier on the table, which one do you choose?". It is not about voting here, or who can gather more friends, it is about reasoned direction to define things through mechanisms. The starting point should be at least those comments (#2924 (comment), #2924 (comment)). Important to understand, "reference token" or "session identifier" should not be taken out of context and watch independently, it is used with pair of self-contained token. One potential starting point is here: https://asvs.dev/v5.0.draft/0x16-V7-Session-Management/ So, ping to @randomstuff @ryarmst @tghosth - as here is a "public call" to say that the terminology you have chosen is incorrect. |
|
Thank you, Elar. I’ve made my perspective clear — not to “win an argument,” but to ensure alignment with the language used in RFCs and standards that developers and educators rely on every day. I invited feedback from others because I respect this community, and their input helps shape a better standard. I’m stepping back from this thread now, in good faith, trusting that the team will make a good decision, regardless of outcome. I appreciate the passion everyone brings to this work and I’ll continue to focus on contributing where I can be most helpful. |
|
You keep repeating that "align with RFCs", so I need to point out my comment on this, that those arguments are questioned and you keep ignoring them: #2924 (comment) Additionally, linked NIST reference does not contain anything about session identifier, they are using "session keys". That is the quality of claims. |
|
it feels like a bit of a round robin going on here's where I"m at: Session Token We already do this for example here Access Control etc... this gives way to reflect modern nuances, but allows more people to understand where the problem exists gravitationally @elarlang are you keen to separate the term or are you malleable to explaining the nuance under what might commonly be known as a parent principle |
|
@yosignals - I'm not sure I understand exactly what you ask, can you please re-phrase it somehow. In general, whatever terminology we use, we need to be able to explain the decisions and/or logic behind it. For "smooth transfer", we need to mention "session identifier" where the context is an opaque CSPRNG value that references to server-side session. And at the same time, we don't do this when it is unnecessary or an invalid limitation for the situation. To validate the terminology we use at the moment: https://github.com/OWASP/ASVS/blob/master/5.0/en/0x90-Appendix-A_Glossary.md
|
|
I mean, both mechanisms seen above are sessions (stateful and stateless), and both token types (reference and self-contained)... are tokens, I suppose the conversation here is does ASVS want parent child terms that get more detailed the deeper the children are (that makes sense to me, that's what I think I'm looking at here based on @tghosth 's original proposition "In some places we use session token and in other places we use session identifier. I think we should use Session Token throughout as it seems the most popular and ties in nicely with our Reference and Self-contained Token terminology." the request for common terms isnt new here, it makes sense to use session tokens as the parent in this area, akin to Input validation is a parent term, Security headers is a parent term and Access control is a parental term or am I completely off the mark ? |
|
In the hope I understood it correctly (simplified example: session token > reference token > session identifier), then yes. The main opposite argument here seems to be that it is incorrect to call a "session identifier" a "reference token" or "session token". I have described potential reasons for this in #2924 (comment):
|
|
Another Tweet
Let me clarify:
|
|
What is more helpful to a web developer reading the standard for the first time? |
|
The summary. I think we are here: #2924 (comment). Thank you to everyone who participated, it "forced" me to think more about every aspect and detail about the chosen terminology and how to explain or defend (like a thesis in school) the chosen direction. Important to note that I am a fact- and argument-based person and I do immediate corrections if I'm proven wrong. Maybe it was not your intention, but now I'm even more sure that our chosen direction is the way to go. What we need to do and achieve is the explanation page and overview of the chosen terms with examples, and why one or another is not correct to use in certain situations. From the not-that-positive side, I need to mention my surprise that a lot of people (including those outside the GitHub thread, as the discussion was also active on LinkedIn) gave advice or opinions without investigating the context of the situation. It is just scratching the surface. Whoever wants to know the rationale behind decisions or wants to challenge me with the chosen direction, you are welcome to contact me directly (for example, in OWASP Slack). |
|
is this a community driven body of work? has there been enough conversation to form a vote and put this to bed, without complicating things more by moving the topic elsewhere, possibly into siloed compartmentalised wasted time |
|
"Enough" is hard to measure, but I think this is one of the longest discussed and shaken topics we have had, taking into account the entire spectrum of state or session management (not just how to call one thing out of context) and fine-tune details for every aspect. |
In some places we use session token and in other places we use session identifier.
I think we should use Session Token throughout as it seems the most popular and ties in nicely with our Reference and Self-contained Token terminology.
The text was updated successfully, but these errors were encountered: