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

[Vittorio Bertocci <[e-mail]>]

Thanks Martin. Inline

I kind of agree that you might want to have this information in the token,
> if possible. You can save a lot of round trips over time (at the expense of
> revocation).

Yep, this entire profile idea emerged as acknowledgement that a large
number of services and products choose to use format driven validation.

 But then, we should simply take that (rfc7662) as a boilerplate for the
> JWT, not OIDC.
> An introspection response also contains scopes, username and optional
> additional claims (e.g. OIDC / authN specific claims)
>
Ultimately all I care about is that we give guidance to developers on on
how to transport in JWT encoded ATs the info their API need. In the initial
formulation I referred to OIDC because in my experience most of the
existing software being used to consume JWT ATs is largely "jury-rigged"
middleware either meant to be used for id_tokens or reusing infrastructure
meant for OIDC (discovery, etc).
As long as the expressive power is the same, I am happy to switch all the
references from OIDC to rfc7662. Developers won't care either ways as long
as they can get the job done.


> I think an access token JWT should not convey more / other information
> than a token introspection endpoint.

Could you expand on this? Could you make a concrete example of a claim you
can get through OIDC that you would not want included in an AT, and why? I
am especially interested in this from the PoV of the 1st party API scenario
I described earlier: if an AT is all you are getting , it seems you should
be able to get any info you could have gotten otherwise.

On Thu, Apr 4, 2019 at 10:40 AM Schanzenbach, Martin <
[e-mail]> wrote:

> Hi Vittorio,
>
> > On 4. Apr 2019, at 19:19, Vittorio Bertocci <Vittorio=
> [e-mail]> wrote:
> >
> > But before I get in the details, let me make an uber-point..
> > I am acutely aware of the potential for confusion and abuse in the
> context of OAuth and sign in, the article you pointed to quotes my own
> articles on the matter extensively. But there are concrete aspects that
> need to be considered about what developers are trying to achieve in
> practice.
> > OAuth2 is the de facto mechanism to secure API calls nowadays. That
> includes scenarios not directly addressed by the spec, such as first party
> APIs. People do that for 1st party APIs as well because they can leverage a
> well supported mechanism for driving authentication experiences and
> outsource authentication to products and services.
> > Forgetting for a second about the fact that 3rd party APIs can use
> identity and authentication levels info as well, let me focus for a second
> on 1st party APIs. From the functionality perspective, delivering an app as
> a web site or as a native client+API combination doesn't change the
> business requirements and the information a backend needs to do its job.
> > Given that we tell people NOT to use ID tokens for calling APIs: if a
> developer chooses to deliver their app as a native client+API instead of a
> web site, the only artifact they have available is the access token. So
> either we embed the info in the access token, and we do what we can to
> prevent abuse and the most likely pitfalls/privacy challenges/etc in the
> guidance, or we find a way for 1st party APIs to consume ID tokens (which
> is problematic- I discussed this with John and Nat at OSW and the place we
> got stuck on was that we can; safely use sender constrain in that scenario).
> > And to pre-empt comments on userinfo, that's asking for a lot of extra
> moving parts- the only outcome will be that people will keep embedding the
> info they need in the AT, but will do so in non-interoperable way, and
> without the guidance and warnings that would at least contain some of the
> damage.
>
> Userinfo is OIDC. Do you mean rfc7662?
> So you say that the use of a token introspection endpoint like rfc7662 is
> not always viable, right?
> I kind of agree that you might want to have this information in the token,
> if possible. You can save a lot of round trips over time (at the expense of
> revocation).
> But then, we should simply take that (rfc7662) as a boilerplate for the
> JWT, not OIDC.
> An introspection response also contains scopes, username and optional
> additional claims (e.g. OIDC / authN specific claims).
> I think an access token JWT should not convey more / other information
> than a token introspection endpoint.
>
> BR
>
> >
> > That said, inline.
> >
> > My concern isn't with reusing the names/types of the claims per se.  But
> more generally that codifying the use of certain authentication-centric
> claims in the context of an access token furthers the potential confusion
> around authentication vs. authorization that has been a nagging problem for
> OAuth (i.e. the https://oauth.net/articles/authentication/ article).
> > see preamble.
> >
> > I  understand what you are saying but but personally do not find it
> sufficiently compelling.  But that's just my opinion and not a hill I want
> to die on (at the present time anyway)..
> > Noted :) does the fact that in some scenarios the AT might be the *only*
> artifact a backend will receive change the stance?
> >
> >  By the time it came up again near the end of the last unconference
> session, I wasn't wanting to prolong things because I was kinda worn out
> for the day and wanting to get to Frankfurt that evening before sunset
> ('cause I like to do stuff like this: https://flic.kr/p/2fiAaPe :) ).
> > Sorry for having tired you out :) at the time I echoed back what was
> suggested (to reflect the original values in the session) precisely to make
> sure everyone had a chance to push back, and I got lots of nods (including
> from John who was in the first row). I misinterpreted your silence as
> assent, given that during that session you did chime in on other matters..
> but I was expecting the discussion to keep going on the ML anyway, so it's
> all according to plan :)
> >
> >  FWIW, to me, George's suggestion "assume[ing] that the auth_time value
> should be updated to the latest time at which the user authenticated"
> though some unspecified and in many cases non-existent link between the AT
> and a current user session at the AS is an example of how
> authentication-centric claims in an access token can be confusing.
> >  I agree it can be confusing, but to me that makes the need to provide
> guidance on it more compelling, not less. There are important scenarios
> where access decisions are made on the basis of that information, and
> implementations WILL find a way to get the info they are interested into.
> To me that's all the more reasons to provide guidance on how to do so being
> aware of pitfalls and with whatever protections we can put in place, as
> opposed to leave developers to their own device.
> >
> > On Thu, Apr 4, 2019 at 9:32 AM Brian Campbell <bcampbell=
> [e-mail]> wrote:
> > A few remarks/responses inline below this time...
> >
> > On Wed, Apr 3, 2019 at 1:38 PM Vittorio Bertocci <Vittorio=
> [e-mail]> wrote:
> > Thanks guys for the comment, sorry for the delay in addressing them.
> > I am not married to the claim types used in here, so if you think that
> reusing the ones in the id_token can cause confusion we should expand on
> the specific ways in which you think might go south.
> >
> > My concern isn't with reusing the names/types of the claims per se.  But
> more generally that codifying the use of certain authentication-centric
> claims in the context of an access token furthers the potential confusion
> around authentication vs. authorization that has been a nagging problem for
> OAuth (i.e. the https://oauth.net/articles/authentication/ article).
> >
> >
> > However I think it's important that the information on say, whether the
> current token was obtained using MFA or a specific authentication factor is
> something that API developers can legitimately latch to when doing
> authorization decisions. From the perspective of a developer modeling a
> solution, whether functionality is delivered as a route in a postback based
> web app (hence receiving an id_token or derived) or as an API consumed by a
> native app, the business requirement gating access to that functionality
> doesn't change. If the admin managing that resource establishes that access
> should be performed only via MFA, the developer should be equipped to
> enforce that regardless of the stack used to expose functionality (web app,
> API).
> > Although it is true that triggering the desired behavior might be
> achieved by the resource setting and contract with the AS, along the lines
> of what David said, it's actually not uncommon for those policies to be
> assigned on the resource AFTER the current session was established and/or
> the corresponding AT was obtained and cached. Furthermore, the requirement
> might be more granular than an AS policy can tolerate (an API might
> requires MFA only for certain routes, hence hard to express in a static
> policy) and triggered in form of challenges. So the situation in which you
> have an AT with the right issuer, audience, etc but was obtained with a
> policy now obsolete/unacceptable to the RP is strong. Requesting to support
> revocation just for this seems overkill, especially given that the scenario
> in which the same logical app is exposed as both web app and native
> client+API, the code consuming those claims is already in place. It just
> makes intuitive sense for developers.
> > In summary, one can take steps to push as much of the MFA requirements
> to the AS settings for a particular request, but ultimately the desire of
> the API developer to enforce that it actually happened is a requirement I
> encountered often in practice. Anything providing extra context to refine
> decisions about it (like auth_time, which might inform decisions about
> whether to accept an MFA check occurred N minutes ago or refuse access).
> >
> > I understand what you are saying but but personally do not find it
> sufficiently compelling.  But that's just my opinion and not a hill I want
> to die on (at the present time anyway)..
> >
> >
> >
> > I thought that reusing the existing names for the same concepts just
> made sense (dev existing skills, existing codebases, etc etc) and
> especially in the case in which the values are exactly the same, and the
> idea seemed to receive good support during OSW.
> >
> > Our recollection of OSW differs somewhat. As I recall there was support
> for pointing to identity claims from OIDC for additional end-user info. But
> there was some grumbling (from John and myself at least) at first mention
> of acr/amr and auth_time. By the time it came up again near the end of the
> last unconference session, I wasn't wanting to prolong things because I was
> kinda worn out for the day and wanting to get to Frankfurt that evening
> before sunset ('cause I like to do stuff like this:
> https://flic.kr/p/2fiAaPe :) ).
> >
> >
> > But I am completely open to change it of course, especially for cases
> like the one identified by George.
> >
> > FWIW, to me, George's suggestion "assume[ing] that the auth_time value
> should be updated to the latest time at which the user authenticated"
> though some unspecified and in many cases non-existent link between the AT
> and a current user session at the AS is an example of how
> authentication-centric claims in an access token can be confusing.
> >
> >
> >
> > WDYT?
> >
> > On Wed, Apr 3, 2019 at 10:24 AM Brian Campbell <bcampbell=
> [e-mail]> wrote:
> > +1 to David's question here. I'd like to see justifying use cases
> (beyond just the fact that some people are already doing it) for auth_time,
> acr, and amr to be available in OAuth JWT access tokens.. Those claims are
> defined for, and in the context of, an ID Token and I fear that codifying
> their use in an access token will lead to misuse and/or confusion.
> >
> > On Mon, Apr 1, 2019 at 1:03 PM David Waite <[e-mail]>
> wrote:
> > Do we know if there is a justifying use case for auth_time, acr, and amr
> to be available in OAuth JWT access tokens? These are meant to be messages
> about the client, either directly (in the case of client credentials) or
> about its delegated authorization of the user.
> >
> > Embedding attributes about the user (such as group membership and roles)
> can be used for the resource to make finer-grained decisions than scopes,
> but normally I would expect say acr limitations enforced by a resource to
> instead be controlled by the AS requiring a higher quality authentication
> to release certain scopes.
> >
> > Thats of course not to say extensions to OAuth such as OIDC can’t
> provide these values, just that they might better be defined by those
> extensions.
> >
> > -DW
> >
> >> On Apr 1, 2019, at 9:12 AM, George Fletcher <gffletch=
> [e-mail]> wrote:
> >>
> >> Thanks for writing this up. One comment on auth_time...
> >>
> >>    auth_time  OPTIONAL - as defined in section 2 of [OpenID.Core
> >> ].
> >>       Important: as this claim represents the time at which the end user
> >>       authenticated, its value will remain the same for all the JWT
> >>       access tokens issued within that session.  For example: all the
> >>       JWT access tokens obtained with a given refresh token will all
> >>       have the same value of auth_time, corresponding to the instant in
> >>       which the user first authenticated to obtain the refresh token.
> >>
> >>
> >> During a current session a user can be challenged for additional
> credentials or required to re-authenticate due to a number of different
> reasons. For example, OIDC prompt=login or max_age=NNN. In this context,
> I'd assume that the auth_time value should be updated to the latest time at
> which the user authenticated.
> >>
> >> If we need a timestamp for when the "session" started, then there could
> be a session_start_time claim.
> >>
> >> Thanks,
> >> George
> >>
> >> 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
> ) - 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
> >>>
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/oauth
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/oauth
> >
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
>
>
> Martin Schanzenbach
> Fraunhofer AISEC
> Department Service & Application Security
> Parkring 4, 85748 Garching near Munich (Germany)
> Tel: [phone]
> [e-mail]
> GPG: 6665201EA9257CC68FDE77E884335131EA3DABF0
>
>