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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
