Hi Vittorio, > On 4. Apr 2019, at 19:19, Vittorio Bertocci > <Vittorio=40auth0....@dmarc.ietf.org> 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=40pingidentity....@dmarc.ietf.org> wrote: > A few remarks/responses inline below this time... > > On Wed, Apr 3, 2019 at 1:38 PM Vittorio Bertocci > <Vittorio=40auth0....@dmarc.ietf.org> 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=40pingidentity....@dmarc.ietf.org> 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 <da...@alkaline-solutions.com> > 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=40aol....@dmarc.ietf.org> 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 >>> >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> 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 > > 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@ietf.org > 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Martin Schanzenbach Fraunhofer AISEC Department Service & Application Security Parkring 4, 85748 Garching near Munich (Germany) Tel: +49 89 3229986-193 martin.schanzenb...@aisec.fraunhofer.de GPG: 6665201EA9257CC68FDE77E884335131EA3DABF0
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
