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 < martin.schanzenb...@aisec.fraunhofer.de> wrote: > 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 > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
