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

Vittorio Bertocci <> Thu, 26 March 2020 00:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A424A3A0805 for <>; Wed, 25 Mar 2020 17:10:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id r4iO1_GMJklr for <>; Wed, 25 Mar 2020 17:10:24 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::833]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E35263A07CF for <>; Wed, 25 Mar 2020 17:10:23 -0700 (PDT)
Received: by with SMTP id m33so3908379qtb.3 for <>; Wed, 25 Mar 2020 17:10:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=rCfxfg30wU3OVvVDjSIvAi5Xn5z331DKh7eFWHMdj/o=; b=DGpwZtE7prrE32zWbXDypssELt0zeVdicvzvilOv1Pq9UYpLbGz+nuTFJTkQqYWv0Q ktfo0gPrZNfScoGAyYd0Tsf3RlDijTFk68MLHhw4rjCcJ24qDB4Jh9cAzNHG0Tz9xnbx hJHBgoYfWy868XwjpeEcPvTq/3yNRy2gehIYsdJEcvPfIU8WMO/nFi6SIA90lsbQ37kG mYWjsRCMq/psZqQLDRFwt0TmGNxEc+wZ8F4Az820iXiJN1PYvc4PIM3ESVFsoFwm2Mcv WwplFWVfl29QLqSh8zySL+keYPOq3aQrMC+xxxJx5Sv650XLh4ue3Jo09IxkCf5D/mqX XKhw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=rCfxfg30wU3OVvVDjSIvAi5Xn5z331DKh7eFWHMdj/o=; b=S0K5cMifRVpPMRFHXpaYtYwf+6uYnxViqiNxzQPe8U4v5/V/0Oef4ul7bNutgsqd+h 8pVZxRwxumwMXRJTcd/HRtMbQpyT8CtL20XesOZ6vQSVqoX+wvmUTEX1kMsJUSMUu1My nRLFLapswFD7CV4H5FMZ5m4oArGe25NatSqktxa6QuG0GEX4dNDXTknmSYTopYqd8ZjC 2BPmcKVrsU/yUfl4XRgPqkXUFGbrZ+a8wbT+PRAg6EHCmRqfVJwXCHOSXChBt09wgsGm 3v5vZK6XFqPgSLocJF8hytb4dxxHZN6tlWXbQAXoSNpchor1869ojJkpVBBVcTUxAoZh LT7A==
X-Gm-Message-State: ANhLgQ0jXa07r4QfqQHZCTTs+9STkoAZelHCIyigxvbJrxSN0wg/XMtk afIv7msyDlqRWG2Az4ctqBzL3A==
X-Google-Smtp-Source: ADFU+vvNwla2L69Ep53onTGEifydtYRvM+gQWiZmpkyXEFqsRZJgKPwKLZn0H7sf8czSbTLnpZcPiw==
X-Received: by 2002:ac8:5694:: with SMTP id h20mr2315005qta.321.1585181422439; Wed, 25 Mar 2020 17:10:22 -0700 (PDT)
Received: from ([2603:1036:301:2079::5]) by with ESMTPSA id n142sm328930qkn.11.2020. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Mar 2020 17:10:21 -0700 (PDT)
From: Vittorio Bertocci <>
To: "Richard Backman, Annabelle" <>, "" <>, 'George Fletcher' <>, 'Brian Campbell' <>
CC: 'oauth' <>
Thread-Topic: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
Thread-Index: AUM3RjQxz4yfrw0VA6wyax1gwRyXXDBEREQ1pBVXVT0=
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Thu, 26 Mar 2020 00:10:20 +0000
Message-ID: <>
References: <> <01ec01d6017c$162eb2e0$428c18a0$> <> <> <> <> <> <> <> <> <13b6801d602c0$02ebea00$08c3be00$> <> <> <> <13c4701d602d5$5990cdc0$0cb26940$> <> <13c7701d602d7$403eccd0$c0bc6670$> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Exchange-Organization-SCL: -1
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/alternative; boundary="_000_DM6PR08MB54026B29CA95A6C3172C2634AECF0DM6PR08MB5402namp_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 26 Mar 2020 00:10:27 -0000

OK, I caught up with the discussion. Very interesting.
It seems that the conclusion is that there’s no simple mechanism we can add at this point that would easily gel with existing deployment, hence either we tell people to STOP using multiple keys, or we make them aware of the futility of doing so as a way of enforcing security boundaries.
Is that the correct conclusion? If yes, I would suggest we use the language I suggested in Brian’s thread (“The RS should expect the AS to use any of the keys published in the JWKS doc to sign JWT ATs”) to warn the RS developer that the AS could do that, and in the security section we warn the AS developer that using multiple keys won’t help much given that the RS won’t differentiate between tokens signed with keys from the same metadata collection anyway, hence it’s enough to compromise one key to generate tokens that will be accepted regardless of type or any other classification.

From: Vittorio Bertocci <>
Date: Wednesday, March 25, 2020 at 16:53
To: "Richard Backman, Annabelle" <>, "" <>, 'George Fletcher' <>, 'Brian Campbell' <>
Cc: 'oauth' <>
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

Oh wow, I completely missed that thread. Thanks for the link. Reading…

From: OAuth <> on behalf of "Richard Backman, Annabelle" <>
Date: Wednesday, March 25, 2020 at 14:26
To: "" <>, 'George Fletcher' <>, 'Brian Campbell' <>
Cc: 'oauth' <>
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

This is another manifestation of the limits of jwks_uri that I’ve brought up on the list previously<>.

Using different signing keys does not actually limit the blast radius of each key, since the validator doesn’t know that each key should only be considered valid for one type of token. This takes away one of the major drivers for using different keys. If the text says deployments can use different keys, it needs to clarify the limited value of that.

Annabelle Backman (she/her)
AWS Identity

From: OAuth <> on behalf of "" <>
Date: Wednesday, March 25, 2020 at 12:01 PM
To: 'George Fletcher' <>, 'Brian Campbell' <>
Cc: 'oauth' <>
Subject: RE: [EXTERNAL] [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

That works for me!

From: George Fletcher <>
Sent: Wednesday, March 25, 2020 11:56 AM
To:; 'Brian Campbell' <>
Cc: 'Brian Campbell' <>; 'oauth' <>
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

If we don't want to give guidance on how the RS determines the correct key to use to validate the token, then maybe we should state that explicitly. "The mechanism used by the RS to determine the correct key to use to validate the access token is out of scope for this specification".

That way at least we are being very clear that the spec is not trying to specify how that happens.

On 3/25/20 2:44 PM,<> wrote:

Brian, there are plenty of ways in which an RS can surprise you with odd behavior- for example, developers might see that you used a key for signing an IDtoken and use that for init all their validation middleware for ATs as well, say because the library only supports one key at a time, and then end up failing at runtime when/if the assumption ceases to apply in the future.

Would that be legitimate of them to take such a dependency, even without warning text? No. However I am not looking at this from the “lawyering up” perspective, but from the useful guidance standpoint as well. I am well aware that being concise is a feature, but I am also not crazy about making every specification into an intelligence test for the reader. If a 16 words sentence can help prevent a likely misstep, I’d be inclined to keep it. But if the consensus is that the sentence is confusing, I can also take it out.

Brian & George, in the spirit of keeping things simple, and given that this was more of a “just in case” warning rather than a security feature clamored for- if the language is problematic I’d be more inclined to take the sentence out rather than complicating the guidance further.

From: Brian Campbell <><>

Sent: Wednesday, March 25, 2020 11:21 AM

To: George Fletcher <><>

Cc: Brian Campbell <><>; Vittorio Bertocci <><>; oauth <><>

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

I don't think you are missing anything, George (except that, to be pedantic, `kid` is a header rather than a claim).

The question gave me pause, however, and makes me think that maybe the draft, with the aim of improved interoperability, should have some more explicit text about the use of the 'kid' header in a JWT AT and how it references the verification key in the content at the jwks_uri.

On Wed, Mar 25, 2020 at 11:54 AM George Fletcher <<> <><> > wrote:

Can we not use the 'kid' claim to inform the RS as to which key is being used? What am I missing?

On 3/25/20 1:51 PM, Brian Campbell wrote:

I think, even without that statement in the draft, that ASes already have

license to use different keys if they so choose. And maybe I'm not creative

enough but I can't think of what problematic assumptions RSes might make

that would prevented by it. So perhaps just removing that whole sentence,

"An authorization server MAY elect to use different keys to sign id_tokens

and JWT access tokens."? Just a thought anyway.

On Wed, Mar 25, 2020 at 10:11 AM <vittorio.bertocci=<> <><> > wrote:

Thank you for the perspective- I guessed something similar (“there would

be no way for the RS to know what key is used for what").

As stated below, the intent wasn’t to prevent substitution/confusion, but

mostly to give ASes license to use different keys if they choose to (for

the reasons listed below, or any other reason they might have) and a

headsup to RSes so that they don’t make assumptions.

*From:* Brian Campbell  <><> <><>

*Sent:* Wednesday, March 25, 2020 8:48 AM

*To:* Vittorio Bertocci  <><> <><>

*Cc:* Richard Backman, Annabelle  <><> <><>; oauth <<> <><> >

*Subject:* Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth

2.0 Access Tokens"

I'm gonna go out on a limb and guess/suggest that implicit in Annabelle's

comment was an assumption that signing ATs and ID Tokens with different

keys would be done to prevent token substitution/confusion. And there's not

really a practical way to achieve that with the mechanics of the jwks_uri..

On Wed, Mar 25, 2020 at 3:53 AM Vittorio Bertocci <vittorio.bertocci=<> <><> > wrote:

*>§4 p3: The only practical way for the AS to sign ATs and ID Tokens with

different keys is to publish the keys in two different JWK sets. This only

way to do this today is by publishing separate OAuth 2.0 authorization

server metadata and OIDC Discovery metadata files, where the JWK set in the

former applies to access tokens and the JWK set in the latter applies to ID


Hmm, I don’t follow. The OIDC jwks_uri can contain multiple keys, and they

all can be used for signing. What prevents the AS to use one key from that

list for IDtokens and another for ATs? Separate discovery docs shouldn’t be

necessary. Sure, there would be no way for the RS to know what key is used

for what- but similar mechanisms are already in place today for handling

signing key rotation: e.g. the discovery doc lists the current key and the

future key, but uses only the current- and the RS has no way of

distinguishing between the two. The situation here can be analogous, any

key in the discovery doc should be considered valid by the RS, and in fact

there’s no requirement about selecting specific keys in the validation

section. That doesn’t mean this is useless, an AS might elect to use

different keys for its own purposes (eg separation of concerns for

forensics, different strengths, different lifecycles, and so on).

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


OAuth mailing list<> <><>


OAuth mailing list<> <><>