The problem is you are making a lot of assumptions that may or may not be true - they are just generally true.
The right to access may be granted without even authenticating a user. For example, a web resource might allow any registered client to have acess to any resource. Only certain scopes require consent. For example, readProfile is public, but updateProfile is restricted. The presumption that receiving an AT would be entirely false in this situation as the user was never even authenticated because consent was not required. We’ve also talked about how access to a resource /Me also binds the name of the authenticate user to the access request. If the API does not have a /Me endpoint, than the identity information you are requesting could be for any person the AT is allowed to see. This creates another “hack” point where clients could be fooled to thinking they have authenticate a particular person when in fact all they have proven is access it a particular resource not necessarily the user is valid. Phil @independentid www.independentid.com phil.h...@oracle.com On Oct 20, 2014, at 12:29 PM, Richer, Justin P. <jric...@mitre.org> wrote: > Right, when you get the AT directly from the token endpoint and it's good for > something, that will *probably* tell you the user is logged in. This is > assuming that the authentication context can also be communicated, audience > restrictions can be communicated, and all the other good stuff the document > talks about. A real problem tends to stem from clients who will take access > tokens from various public endpoints and use them directly (implicit clients > are inherently open to this problem). Or that an access token can have a life > long past the authentication event, so if a client saves the access token off > someplace, does a bunch of work, then finally asks "Who's there?" and makes > the user info API call, it's going to get info but not necessarily what it > assumes. > > Really, all of this is why there's the ID Token and the Signed Request > components in OIDC and FBC, respectively. Plus you don't always want the > profile information on every request, so having something the client can read > directly saves a round trip to fetch data it doesn't really want. Having the > separation between the authentication context and the profile information > really does make the code paths a bit simpler. > > -- Justin > > On Oct 20, 2014, at 3:20 PM, Hans Zandbelt <hzandb...@pingidentity.com> wrote: > >> My point is that it *is* a guarantee if the AT just came to the client in a >> code flow; I don't see a problem with that although clients have to be aware >> of what they're doing and not allow any other flows for this. >> >> Hans. >> >> On 10/20/14, 9:04 PM, Richer, Justin P. wrote: >>> This is actually one of the sticky bits that I've tried to address in the >>> document itself -- I've seen apps that assume that if they're given an >>> access token that can be used to fetch profile information then the user is >>> actually there. This isn't actually a guarantee, but it's commonly true >>> enough that developers get lazy and rely on it. >>> >>> -- Justin >>> >>> >>> On Oct 20, 2014, at 2:42 PM, Hans Zandbelt <hzandb...@pingidentity.com> >>> wrote: >>> >>>> or pointier: there are OAuth 2.0 deployments today that offer login >>>> semantics because they have a REST/JSON user profile API that can be >>>> accessed using the AT that was obtained in a code flow; should that be >>>> acknowledged in the doc? >>>> >>>> Hans. >>>> >>>> On 10/16/14, 11:23 PM, Hans Zandbelt wrote: >>>>> a deployment-related question that I have around this topic: >>>>> >>>>> it seems that authentication using OAuth 2.0 is possible today for >>>>> confidential clients using the code flow, with a registered >>>>> redirect_uri, not consuming/storing/using refresh_tokens, and assuming >>>>> that there's an API that returns user identity info in JSON format and >>>>> the claim that uniquely identifies the user is known by the client. >>>>> >>>>> The usage/presence of the short-lived code in this scenario/flow >>>>> guarantees that the user has just authenticated, and the audience issue >>>>> is covered by the fact that the code (thus the access_token in the token >>>>> endpoint response) are bound to the confidential client, all as per >>>>> standard OAuth 2.0 semantics. >>>>> >>>>> 2 questions about that: >>>>> - is this right or am I overlooking some security/semantics issues here >>>>> - if right, would it make sense to acknowledge that or is that muddying >>>>> the waters even more (the current text does seem to only implicitly >>>>> acknowledge this) >>>>> >>>>> There may be value in acknowledging this because the majority of OAuth >>>>> 2.0 OPs exposing a userinfo-like API would adhere to a REST GET+JSON >>>>> response anyhow [1] thus achieving login semantics with plain OAuth 2.0 >>>>> and a bit of common practice wrt. the user info API. >>>>> >>>>> Thanks for the excellent write-up! >>>>> >>>>> Hans. >>>>> >>>>> PS: I've been asked this concrete question about Spotify's OAuth 2.0 >>>>> support and in fact I'm able to configure Spotify as an IDP to my OIDC >>>>> client with a minor workaround to abstain from expecting an id_token in >>>>> the token endpoint response, but calling the Spotify specific user info >>>>> endpoint like it was a standards-compliant OpenID Connect endpoint. (the >>>>> client has a per-OP configurable unique user id claim name anyhow). >>>>> >>>>> On 10/16/14, 7:27 PM, Richer, Justin P. wrote: >>>>>> Ah yes, good catch! If only someone would put up a webpage describing >>>>>> the difference between authorization and authentication and why people >>>>>> need to stop confusing the two. >>>>>> >>>>>> Oh wait... >>>>>> >>>>>> >>>>>> On Oct 16, 2014, at 1:06 PM, Hans Zandbelt >>>>>> <hzandb...@pingidentity.com> wrote: >>>>>> >>>>>>> About the write-up: at the end of the metaphor section it says: >>>>>>> "These recipes each add a number of items, such as a common profile >>>>>>> API, to OAuth to create an authorization protocol." >>>>>>> >>>>>>> whereas I believe that should read "to create an authentication >>>>>>> protocol" >>>>>>> >>>>>>> Hans. >>>>>>> >>>>>>> On 10/16/14, 6:54 PM, Hannes Tschofenig wrote: >>>>>>>> Participants: >>>>>>>> >>>>>>>> * Brian Campbell >>>>>>>> * John Bradley >>>>>>>> * Derek Atkins >>>>>>>> * Phil Hunt >>>>>>>> * William Kim >>>>>>>> * Josh Mandel >>>>>>>> * Hannes Tschofenig >>>>>>>> >>>>>>>> >>>>>>>> Notes: >>>>>>>> >>>>>>>> Justin distributed a draft writeup and explained the reasoning behind >>>>>>>> it. The intended purpose is to put the write-up (after enough >>>>>>>> review) on >>>>>>>> oauth.net. See attachments. Justin solicited feedback from the >>>>>>>> conference call participants and from the working group. >>>>>>>> >>>>>>>> One discussion item was specifically related to the concept of audience >>>>>>>> restrictions, which comes in two flavours: (a) restriction of the >>>>>>>> access >>>>>>>> token regarding the resource server and (b) restriction of the id token >>>>>>>> regarding the client. Obviously, it is necessary to have both of these >>>>>>>> audience restrictions in place and to actually check them. >>>>>>>> >>>>>>>> The group then went into a discussion about the use of pseudonyms in >>>>>>>> authentication and the problems deployments ran into when they used >>>>>>>> pseudonyms together with a wide range of attributes that identified >>>>>>>> users nevertheless. Phil suggested to produce a write-up about this >>>>>>>> topic. >>>>>>>> >>>>>>>> Finally, the group started a discussion about potential actions for the >>>>>>>> OAuth working groups. Two activities were mentioned, namely to produce >>>>>>>> an IETF draft of the write-up Justin has prepared as a "formal" >>>>>>>> response >>>>>>>> to the problems with authentication using OAuth and, as a second topic, >>>>>>>> potential re-chartering of the OAuth working group to work on some >>>>>>>> solutions in this area. Hannes suggested to postpone these discussions >>>>>>>> and to first finish the write-up Justin had distributed. >>>>>>>> >>>>>>>> Ciao >>>>>>>> Hannes & Derek >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>> hzandb...@pingidentity.com | Ping Identity >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>> >>>> >>>> -- >>>> Hans Zandbelt | Sr. Technical Architect >>>> hzandb...@pingidentity.com | Ping Identity >>> >> >> -- >> Hans Zandbelt | Sr. Technical Architect >> hzandb...@pingidentity.com | Ping Identity > > _______________________________________________ > 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
