[OAUTH-WG] a token review of draft-ietf-oauth-access-token-jwt-01/-02

Brian Campbell <bcampbell@pingidentity.com> Wed, 24 July 2019 19:59 UTC

Return-Path: <bcampbell@pingidentity.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 798DF120640 for <oauth@ietfa.amsl.com>; Wed, 24 Jul 2019 12:59:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id fxMV9zSkDRLO for <oauth@ietfa.amsl.com>; Wed, 24 Jul 2019 12:59:33 -0700 (PDT)
Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1625C12066B for <oauth@ietf.org>; Wed, 24 Jul 2019 12:59:33 -0700 (PDT)
Received: by mail-io1-xd2c.google.com with SMTP id s7so92100942iob.11 for <oauth@ietf.org>; Wed, 24 Jul 2019 12:59:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to; bh=PEzLPm550VNupfpvHGYW2LV3sZen8KQCewSlwmP3JTU=; b=hEpzWf+iekC3nG/IZfE8OeDgoEVxiThpJ2KiO8MSeNR6PAniYDG5VViX0SK+eLaSwv SHbGryGRwjCsaHqas3Fkh59qrrvpW9eUrnBpCzpcebuyaplMeOwFulswJS5djDvxCzME sA9/8ts4oadeFVIoRDI75WY7U6RSVCp5HYU1I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=PEzLPm550VNupfpvHGYW2LV3sZen8KQCewSlwmP3JTU=; b=Cn4/k3+MSYxQxVZUSqCL2317fvttdkSmJmg/HC+hSqruSAqVYQXcdvdmsfBgjLVE2C YCu2Kp7iNtbK9Rk/kq6Px0Ha9L7wcvso4KB4azEt/4CLX9K/WJ1/GNEmfwmSkP77vEMJ Pj10g9ahyE0ykP8H8OkHTfDANCWk/9l3cUJrAVUkFUWT4K/KyC5FxCoRr430zbZC0uEk PAIZh1qFnxj0FGL1eO2OTdag2Q921k+hG+zlujy9CNpZR92PwE/XgyquwoUZ0OJQB2su XNj2Q8lA/7ejaK7hTSNuVjsVYv97d/Gp2e3Kcafz6U+6laAuqIOWe7hRNs2vrqyXvgGA 3XLg==
X-Gm-Message-State: APjAAAVPWM+9ShcGr5esnTRgIBPKu64g5CYhJ2YdUjr9dnUgKaa1Gffb OQrBTE21fVeeYnE3OdnY21AAmoLO8X1TAcUrfcwu3djWyDWsACzruZ/yuFDKFSysl35g6HtS8T6 oKHGEAgxYRE2YTTfcPM9+rA==
X-Google-Smtp-Source: APXvYqyoHNPnWyDZ7lJ6fjuZTo7WNDhKhM3uNSw/c4XAQf95c/qkmwrQDZ5HCteZrgzba6UMB5fd0a43zJbUYWB3URw=
X-Received: by 2002:a6b:621a:: with SMTP id f26mr70003330iog.127.1563998371926; Wed, 24 Jul 2019 12:59:31 -0700 (PDT)
MIME-Version: 1.0
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Wed, 24 Jul 2019 13:59:05 -0600
Message-ID: <CA+k3eCT5A7P3QZrst_mkd6-s4PYzTO+UeabAcy5BJKQ05DvWww@mail.gmail.com>
To: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000637483058e72bf18"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/BWH6BEhKt29aJ4TUYtcLckdCqO4>
Subject: [OAUTH-WG] a token review of draft-ietf-oauth-access-token-jwt-01/-02
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2019 19:59:44 -0000

2.1.  Header

>    NOTE: there were discussions about adding a reference to
>    authenticated encyption methods as well, but there's no internet
>    draft specifying interoperable public key methods at this time
Well, Neil did write this up a while back
https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-01 which is
certainly interesting and I wonder if it's something that this group (or
some other group?) should look at working on. But it is only an individual
draft (with all the authority that brings to bear
<https://tools.ietf.org/html/draft-abr-twitter-reply-00>) and thus I do
agree that it isn't appropriate or useful for this document to reference.

However JWE RFC7516 and more JWA RFC7518 do have authenticated encryption
with symmetric keys that, IMHO, can work very nicely in some cases for JWT
access tokens by providing both integrity protection and confidentiality.
And the size and performance benefits thereof can be sufficiently useful so
as to justify the need to do an out-of-band exchange of the symmetric key.

Also encyption should be encryption.

2.1.  Header

>    The typ header parameter for a JWT access token MUST be at+jwt.  See
>    the security considerations section for details on the importance of
>    preventing JWT access tokens to be interpreted as id_tokens.

5.  Security Considerations

>    The JWT access token data layout described here is very similar to
>    the one of the id_token as defined by [OpenID.Core].  Without the
>    explicit typing required in this profile, in line with the
>    recommendations in [JWT.BestPractices] there would be the risk of
>    attackers using JWT access tokens in lieu of id_tokens.

Connect doesn't say anything about checking the "typ" header of id tokens
so typing ATs with "at+jwt" doesn't actually do anything to prevent JWT
access tokens being used as id tokens. It can prevent misuse in the other
direction. But this document probably shouldn't overstate what typing the
JWT can accomplish.

BTW, there's been some discussion and agreement that the requirement around
'nonce' in ID Tokens delivered via the front channel (the only time connect
is subject to that kind of token swapping) is sufficient to protect against
JWT access tokens (and other types of JWTs) to be interpreted as id_tokens.
So I think the risk is acceptable but just think the text in the draft
shouldn't make claims which are untrue.

2.2.2.  Authorization Claims:

>    If an authorization request includes a scope parameter, the
>    corresponding issued JWT access token
  MUST in -01/SHOULD in -02 include a scope claim
as defined in
I think you want to say here that the scope claim in the token has to
correlate to the scope which was approved. Not necessarily what what
requested. The authorization request might ask for scope of a+b+c, for
example, while the user only approves b. Or any other variation on things
where what was asked for isn't what was gotten.

3.  Requesting a JWT Access Token

>    If it receives a request for an access token containing more than one
>    resource parameter, an authorization server issuing JWT access tokens
>    MUST reject the request and fail with invalid_request as described in
>    section of [RFC6749].
https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators has an
"invalid_target" error code that is intended for this kind of thing. So
that should probably be allowed. If not suggested. Probably not required

4.  Validating JWT Access Tokens

>       If encryption was negotiated with the
>        authorization server at registration time and the incoming JWT
>        access token is not encrypted, the resource server SHOULD reject
>        it.
I personally think the SHOULD is too strong here because it puts the onus
on the resource server to know about (via some config option or something)
and enforce on every transaction a setup/policy thing that the AS is
responsible for which isn't about the integrity of the authorization data
in the token. A MAY or even removing the list item would be preferred.

4.  Validating JWT Access Tokens

>      The JWT access token MUST be
>        rejected if aud does not list the resource indicator of the
>        current resource server as a valid audience, or if it contains
>        additional audiences that are not known aliases of the resource
>        indicator of the current resource server.
5.  Security Considerations

>    This profile explicitly forbids the use of multi value aud claim when
>    the individual values refer to different resources, as that would
>    introduce confusion about what scopes apply to which resource-
>    possibly opening up avenues for elevation of delegated privileges
>    attacks.  Alternative techniques to prevent scope confusion include
>    "scope stuffing", imposing to every individual scope string to
>    include a reference to the resource they are meant to be applied to,
>    but its application is problematic (scope opacity violations, size
>    inflation, more error conditions become possible when the combination
>    of requested scopes and resource indicators is invalid) and the
>    observed frequency of the scenario doesn't warrant complicating the
>    more common cases.
I do think I see the simplification you're aiming at with this stuff but
I'd like to offer the perspective of how this is likely more complicated
for standards based JWT library implementations. The semantics of aud in
RFC 7519 basically say that the recipient has to identify with at least one
of the aud values. It's effectively a big OR. While the text in this draft
changes that semantic to say that the recipient has to identify with at
every one of the aud values. Effectively making it a big AND. Normal JWT
libraries will need nonstandard one-off functionality or adaptations to get
this right.

 4.  Validating JWT Access Tokens

>       The resource server MUST validate the signature of all incoming
>        JWT access token according to [RFC7515] using the algorithm
>        specified in the JWT alg Header Parameter.  The resource server
>        MUST use the keys provided by the authorization server.
I think it'd be worthwhile to explicitly disallow the use of the "none"
algorithm here. I think/suspect that it is implied already. But at least
some of the JWT hate out there seems to stem from or focus on statements
like this one and conclude that words like "MUST validate ... according to
[the] algorithm specified in the JWT alg Header Parameter" means that to be
spec compliant one has to accept "alg":"none" as valid. That's more of a
logical leap than I think is reasonable but I'd like to avoid it anyway if
possible. And it's not a bad thing to remind folks not to accept "none"

7.2.  Claims Registration

>     claims in the JSON Web TOken (JWT) IANA
Little 'o' in TOken -> Token

7.2.1.  Registry Contents
|   Specification Document(s): section 4.1.2 of [RFC7643]
Ultimately this is what will show up in the "References" column in the
registry https://www.iana.org/assignments/jwt/jwt.xhtml and thus I'd
suggest that it also include something like "Section of [[this
specification]]" there too so someone who starts from the registry has the
link to and context of this document. A link directly to SCIM alone from
the JSON Web Token Claims registry might be rather confusing.
For the folks that will have to review and act on these registrations at
some point, it might be nice to give em a little better
grouping/formatting. I'm thinking along the lines of what is done here
which you can corice xml2rfc into doing with <?rfc subcompact="yes"?> and <?
rfc subcompact="no"?> as in the src at

Appendix A.  Acknowledgements

>     Brian Campbell (PingIdentity)
My corporate overloads will be happier if you put a space between Ping and

_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._