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

[Vittorio Bertocci <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> *On Behalf Of *Hannes Tschofenig
> *Sent:* Monday, March 23, 2020 11:18 PM
> *To:* oauth <[e-mail]>
> *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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>