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

["Schanzenbach, Martin" <[e-mail]>]

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