Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

Thanks Nikos!
You are right that the goals of the two specs are different; however the current spec reflects in large part both what was observed in the proprietary JWT ATs in existing systems (hence making interop more likely/meeting a need that seems widespread) and the current practice of abusing id_tokens for calling API. People do that because their API do leverage the info in the id_token, and include those info in their custom use of JWT for ATs for the same reason. If you add to this the fact that a lot of popular libraries would actually not validate the token if it would not comply with the validation requirements in OIDC, I think we can conclude there’s value in specifying those settings are requirements for successful interop.

From: Nikos Fotiou <fotiou@aueb.gr>
Date: Tuesday, March 24, 2020 at 13:55
To: 'Vittorio Bertocci' <Vittorio@auth0.com>
Cc: 'Hannes Tschofenig' <Hannes.Tschofenig@arm.com>, 'oauth' <oauth@ietf.org>
Subject: RE: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

Just a general comment, OIDC has been designed for a specific reason (“identity layer on top of the OAuth 2.0”) whereas JWT access tokens are used for more applications. Since the goal of this specification is to “provide a standardized and interoperable profile as an alternative to the proprietary JWT access tokens layout”,  I feel it is restrictive.

Best,
Nikos

From: Vittorio Bertocci <Vittorio@auth0.com>
Sent: Tuesday, March 24, 2020 7:57 PM
To: Nikos Fotiou <fotiou@aueb.gr>
Cc: Hannes Tschofenig <Hannes.Tschofenig@arm.com>; oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

Hi Nikos,
thanks for taking the time to review and write down your feedback!
Inline

- In Section 2.2 why nbf claim (https://tools..ietf.org/html/rfc7519#section-4.1.5)<https://tools.ietf.org/html/rfc7519#section-4.1.5)> is not considered? I can imagine some interesting applications of this claim.
The validation rules are partly following the ones defined in OpenID Connect, given that a lot of in market deployments reuse some low level JWT validation components.

  - In the same section, it is not clear why some claims are required, especially exp, sub, and client_id. The last two claims are not even used during token validation.
 Being this an interop profile, it reflects the information commonly found in many existing JWT based access tokens solutions in the wild. Both sub and client_id provide information that proved to be useful to RSes and SDKs/middlewares, hence guaranteeing their presence will help creating reusable libraries with broader applicability. The AS has ready access to that info, and there are no obvious security reasons for omitting them. Also, sub and exp are both required in OIDC, and clientID is available via aud (also required) - hence requiring their presence helps developers to reuse existing validation logic to at least some extent.

  - RFC7519 specifies that, in the general case, the aud claim is an array of StringOrURI values. In this draft it is not clear if this still the case, or here aud is a simple string (e.g., in page 5 it is stated: the resource indicated in the aud claim, rather than the resource*s*).
For simplicity, and above all for avoiding ambiguity in evaluating to what resource the granted scopes should be applied to, the idea would be to restrict to a single string.

  - In the token validation procedure, i.e., Section 4, is there any reason why the resource server first checks the aud claim, then the signature, and finally the exp claim? Given the fact that Error responses are not specified, returning something like “invalid aud claim” even for tokens with invalid signature may result in privacy/security attacks.
 The sequence of those checks follows https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation.  As OIDC doesn't define error responses nor call this aspect out in the security considerations, I largely relied on this being mainstream.

  - IMHO The token validation procedure it too bound to the particular discovery mechanisms mentioned at the beginning of this section. E.g., Step 2 mentions a “registration” process, and Step 3 mentions and an “Issuer Identifier” which must much the iss claim. Moreover, I think it should be explicitly mentioned that the resource server “must validate that the JWT access token has been singed with a signing key that corresponds to the authorization server included in the iss claim”
As per the other points, the language follows closely OIDC.
The step does contain the phrase "The resource server MUST use the keys provided by the authorization server." Do you feel the language should be more explicit? The document doesn't specify any other mechanism for acquiring keys, hence it shouldn't be too ambiguous... but we can always tighten it up.

On Mon, Mar 23, 2020 at 6:32 PM Nikos Fotiou <fotiou@aueb.gr<mailto:fotiou@aueb.gr>> wrote:
Hi all,

Allow me some comments and forgive me if some of them are naïve.
- In Section 2.2 why nbf claim (https://tools..ietf.org/html/rfc7519#section-4.1.5)<https://tools.ietf.org/html/rfc7519#section-4.1.5)> is not considered? I can imagine some interesting applications of this claim.
- In the same section, it is not clear why some claims are required, especially exp, sub, and client_id. The last two claims are not even used during token validation.
- RFC7519 specifies that, in the general case, the aud claim is an array of StringOrURI values. In this draft it is not clear if this still the case, or here aud is a simple string (e.g., in page 5 it is stated: the resource indicated in the aud claim, rather than the resource*s*).
- In the token validation procedure, i.e., Section 4, is there any reason why the resource server first checks the aud claim, then the signature, and finally the exp claim? Given the fact that Error responses are not specified, returning something like “invalid aud claim” even for tokens with invalid signature may result in privacy/security attacks.
- IMHO The token validation procedure it too bound to the particular discovery mechanisms mentioned at the beginning of this section. E.g., Step 2 mentions a “registration” process, and Step 3 mentions and an “Issuer Identifier” which must much the iss claim. Moreover, I think it should be explicitly mentioned that the resource server “must validate that the JWT access token has been singed with a signing key that corresponds to the authorization server included in the iss claim”

Best,
Nikos

From: OAuth <oauth-bounces@ietf.org<mailto:oauth-bounces@ietf.org>> On Behalf Of Hannes Tschofenig
Sent: Monday, March 23, 2020 11:18 PM
To: oauth <oauth@ietf.org<mailto:oauth@ietf.org>>
Subject: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

Hi all,

this is a working group last call for "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens".

Here is the document:
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-04

Please send you comments to the OAuth mailing list by April 6, 2020.

Ciao
Hannes & Rifaat
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth