Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

[Vittorio Bertocci <[e-mail]>]

Hey George! Thanks for the comments. nline

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

Fair enough. We do provide more specific guidance on the use of audience
for API, the language you quote later on being an example of that.

 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.

We embedded that in the client_id claim. I originally had azp but got
strong pushback, given the debacle it caused in the past (see
https://bitbucket.org/openid/connect/issues/1009/contradictory-statements-about-id-token?fbclid=IwAR2iPZcEStXGXB-9SW0889Ky1cpKbK8h1WdjyQX2PKMly4nN6050Na4KfYw
,
https://bitbucket.org/openid/connect/issues/973/core-2-3137-azp-claim-underspecified-and?fbclid=IwAR0IN6JT_jPqukOzsbegJLY2MXl1xnplURjXoxSyhd3kvgfw6Nj6LsPLU5M
).

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.

This is an interesting point. In my experience, the main boundary used to
define a resource is either reflecting an underlying, *actual* resource
that exists independently of the API facade slapped on top of it (say a VM)
or it is the context within a certains et of scopes makes sense (say an API
facading access to a bunch of documents).
Some of that criterion is reflected in the rationale for sigle value
audiences. Do you think it should be made more explicit? Perhaps in a
dedicated section?

On Thu, Apr 4, 2019 at 7:07 AM George Fletcher <[e-mail]> wrote:

> 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 [e-mail]://www.ietf.org/mailman/listinfo/oauth
>
>
>