Another comment...
aud REQUIRED - as defined in section 2 of [OpenID.Core
<https://tools.ietf.org/html/draft-bertocci-oauth-access-token-jwt-00#ref-OpenID.Core>].
See
Section 3
<https://tools.ietf.org/html/draft-bertocci-oauth-access-token-jwt-00#section-3>
for indications on how an authorization server should
determine the value of aud depending on the request. [Note: some
vendors seem to rely on resource aliases. If we believe this to
be a valuable feature, here's some proposed language: The aud
claim MAY include a list of individual resource indicators if they
are all aliases referring to the same requested resource known by
the authorization server. ]
I don't think OpenID.Core Section 3 is the correct reference for
determining the 'aud' value. The issue here is that the 'aud' of the
id_token is the recipient of the id_token (i.e. the client). However,
for access_tokens the 'aud' value should be the resource service that
will receive the access_token. There is no existing guidance for this
and we should provide such guidance as this is "kind of new" for OAuth2
(from an explicit specification perspective).
Also, there is the concept of 'azp' from the id_token which amounts to
"who's allowed to present this token" which might be interesting from
the case where one entity obtains the token, and gives it to another
entity to present. Not sure if we want to include this concept or not.
Finally, I think we may need some best practice around how the concept
of audience and resource should be managed. For instance...
If the request does not include a resource parameter, the
authorization server MUST use in the aud claim a default resource
indicator. If a scope parameter is present in the request, the
authorization server SHOULD use it to infer the value of the default
resource indicator to be used in the aud claim.
I think for most implementations this would amount to... define an
audience that covers all the resource services where the access token
can be returned and set that as the audience (e.g. urn:x-mydomain:apis).
Which is perfectly legal but maybe not in the spirit of the spec:) I am
receiving feedback from developers that binding access tokens narrowly
to the resource where they will be presented is concerning from a
chattiness perspective (latency issues) and general load on the deployed
AS infrastructure.
On 3/24/19 7:29 PM, Vittorio Bertocci wrote:
Dear all,
I just submitted a draft describing a JWT profile for OAuth 2.0 access
tokens. You can find it in
https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting
remotely). I look forward for your comments!
Here's just a bit of backstory, in case you are interested in how this
doc came to be. The trajectory it followed is somewhat unusual.
* Despite OAuth2 not requiring any specific format for ATs, through
the years I have come across multiple proprietary solution using
JWT for their access token. The intent and scenarios addressed by
those solutions are mostly the same across vendors, but the syntax
and interpretations in the implementations are different enough to
prevent developers from reusing code and skills when moving from
product to product.
* I asked several individuals from key products and services to
share with me concrete examples of their JWT access tokens (THANK
YOU Dominick Baier (IdentityServer), Brian Campbell
(PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta)
for the tokens and explanations!).
I studied and compared all those instances, identifying
commonalities and differences.
* I put together a presentation summarizing my findings and
suggesting a rough interoperable profile (slides:
https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx
<https://sec..uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx>
) - got early feedback from Filip Skokan on it. Thx Filip!
* The presentation was followed up by 1.5 hours of unconference
discussion, which was incredibly valuable to get tight-loop
feedback and incorporate new ideas. John Bradley, Brian Campbell
Vladimir Dzhuvinov, Torsten Lodderstedt, Nat Sakimura, Hannes
Tschofenig were all there and contributed generously to the
discussion. Thank you!!!
Note: if you were at OSW2019, participated in the discussion and
didn't get credited in the draft, my apologies: please send me a
note and I'll make things right at the next update.
* On my flight back I did my best to incorporate all the ideas and
feedback in a draft, which will be discussed at IETF104 tomorrow.
Rifaat, Hannes and above all Brian were all super helpful in
negotiating the mysterious syntax of the RFC format and submission
process.
I was blown away by the availability, involvement and willingness to
invest time to get things right that everyone demonstrated in the
process. This is an amazing community.
V.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
