proposal/discussion: JWT - 3.5.6 add "type", and rephrase it to describe the goal

[elarlang]

spin-off from #1925 "proposal 4"

From @TobiasAhnoff

4 Verify that only access-tokens are used for authorization by the RS (not id-tokens or other kinds of tokens)

Proposal from me:

I think we should add typ (RFC7519) to this requirement:

#	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

Response from @TobiasAhnoff

I agree, this could be part of 3.5.6

---

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.

[elarlang]

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

[jmanico]

A few notes:

1. Even though it's covered elsewhere, it's a bit weird to talk about security-centric attributes that do not include the signature - the most essential security-centric attribute.

2. Here is a list of other security-centric attributes to consider for the requirement text:

• Expiration (exp)
• Issued At (iat)
• Not Before (nbf)
• Audience (aud)
• Issuer (iss)
• Subject (sub)
• JWT ID (jti)
• Scopes/Permissions

And of course:

• Signature
• Algorithm (alg)

[elarlang]

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".

[jmanico]

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:

• Expiration (exp) - 3.5.4
• Issued At (iat) - Not Covered yet
• Not Before (nbf) - Not Covered yet
• Audience (aud) - 3.5.6
• Issuer (is) - 3.5.6
• Subject (sub) - 3.5.6
• JWT ID (jti) - Not covered yet
• Scopes/Permissions - Not converted in 3.5.x
• Signature - Covered in 3.5.3 but I think the text needs to be a bit clearer
• Algorithm (alg) - Covered in 3.5.5, but the specific claim (alg) is not mentioned

[elarlang]

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.

• iat - I don't think you need to validate that anyhow for security decisions, for that there is nbf
• nbf - I have addressed in the cleanup V3.5 Token-based Session Management #1917, see 3.5.4
• jti - it is identifier and I don't think you need to validate it (from this requirement/issue scope point of view), also it is a optional parameter. In a way related to Add requirement about usage of claims other than subject and issuer as an identifier for OpenID Connect #1826

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.

[elarlang]

Scopes/Permissions - Not converted in 3.5.x

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

[TobiasAhnoff]

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)

[elarlang]

The requirement should be independent without references to other requirements or sections.

[TobiasAhnoff]

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):

• Issuer, is it signed by a CSP that the service trusts?
• Expiration, is it valid at this point in time?
• Intended usage, is it an access-token (not another kind of token) meant for this particular service and kind of operation?

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)?

[elarlang]

Original reason to open the issue:

4 Verify that only access-tokens are used for authorization by the RS (not id-tokens or other kinds of tokens)

it is / will be covered by #2005 (comment)

Verify that tokens (such as ID tokens, access tokens and refresh tokens) can only be used according to their intended purpose without allowing cross-usage between them.

(the final wording can be changed/updated)

In the requirement 3.5.6 is not defined, why it exists:

... in a JWT this may include issuer, subject, and audience.

By checking:

• issuer - who made the token
• subject, aud - for whom it is made (related V51 OAuth: Add new OIDC Client verifications #2048)