-
-
Notifications
You must be signed in to change notification settings - Fork 665
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
proposal/discussion: JWT - 3.5.6 add "type", and rephrase it to describe the goal #1967
Comments
Note, I labeled it as V51, although it is not OAuth-specific. Also, at the moment it belongs to V3 Session management, but it is not related to sessions. It should belong to V13 - for that discussion, there is a separate issue:#1917 |
A few notes:
And of course:
|
Jim, you should take a look at section V3.5 first, and see, which one of them is already covered by other requirements. But this is precisely the reason for proposal 2 - that we should define the clear goal, why you need to verify aud, iss, sub, typ and keep the focus only on those. Also note, that even the current requirement lists them as "For example". |
Sounds good, Elar. I just wanted to provide the complete list here for consideration. I did read the entire thread before I commented. Here is what I see for the main list of token claims:
|
In my opinion, this requirement/issue focuses only on "Verify that the token is generated by an expected party" and "Verify that the token is meant for this usage". As it is not clearly defined (yet), it can cause confusion.
If something needs to be improved, please open separate issues for those - let's keep the issue here clear and focused on solving this one and precise problem, not covering the entire section or paragraph. |
I think the scope and permission is not general JWT topic, but it comes from OAuth 2.0 Token Exchange. For that discussion we have #1964 |
Given level of detail for other 3.5 verifications a suggestion is to merge 3.5.4 into 3.5.6 (and remove 3.5.4), like this: 3.5.6 - "Verify that any security-sensitive attributes of a stateless token are being verified before processing it further. For example, issuer, expiration and intended usage. Note that the exact list of attributes depends on token format, for JWT see chapter 13.??". The new 13.?? section could be JWT specific and have a list claims to verify details like alg, iss, aud, exp, nfb, typ etc, maybe also add a reference to a JWT cheat sheet (or JWT RFC on token validation) |
The requirement should be independent without references to other requirements or sections. |
Should 3.5 be independent of token format (without e g JWT or SAML detalails)? If so, then 3.5.6 could be 3.5.6 - "Verify that security-sensitive attributes of a stateless token are being verified before processing it further. Regardless of token format, the following must be verified by the service protecting resources (e g an API):
And then have specific token verification details in chapter 13, for e g JWT and SAML, without reference in 3.5.6. But, perhaps also add a note in chapter 3 text to make it clear for the reader that specific token format details are found in chapter 13 (as 3.5 is independent of token format)? |
Original reason to open the issue:
it is / will be covered by #2005 (comment)
(the final wording can be changed/updated) In the requirement 3.5.6 is not defined, why it exists:
By checking:
|
spin-off from #1925 "proposal 4"
From @TobiasAhnoff
Proposal from me:
Response from @TobiasAhnoff
Proposal/Goal 1: add
typ
(Type) to the requirement to have special spotlight for it in OAuth context.The question: should the requirement list issuer, subject, audience, and type - or iss, sub, aud, and typ?
Proposal/Goal 2: get rid of "that other" part and describe why this requirement exists defining the goal to ask those parameters to be verified.
The CWE-287 is "Improper Authentication", which I would say is not correct. Additionally, it points to CWE "Class" or "Category" and should not be used for mapping.
The text was updated successfully, but these errors were encountered: