-
-
Notifications
You must be signed in to change notification settings - Fork 666
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cleanup V3.5 Token-based Session Management #1917
Comments
3.5.1 - Agree it should be part of the OAuth Chapter 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. |
Let's try to get the first 2 sorted... 3.5.1Thinking 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.7We 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". bothTill 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 |
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 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 |
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." |
We can't revoke the token if it is really stateless, though. |
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.
|
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. |
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. |
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:
Some examples in the wild:
|
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 |
Before we move 3.5.7 I want to make a comment.
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:
|
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. |
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:
|
I suggest a change to 3.5.3 from:
to
This accounts for the comments above as well. |
"HMAC" should be replaced by "MAC": any other (non-broken) MAC could be used. (Would it be useful, to mention authenticated encryption algorithms here?) |
"before processing further" is somewhat vague/ambiguous. |
So how about:
It's a LOT more specific, but too much so? |
Each requirement has now a separate issue for discussion and not to be discussed here:
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. |
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
3.5.1
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:
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
3.5.3 should not be limited with "stateless session tokens", just "stateless tokens".
Not a session specific requirements.
3.5.4
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
Not a session specific requirement.
3.5.7
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:
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.
The text was updated successfully, but these errors were encountered: