I can’t give names or numbers but yeah, it’s happening. Especially for Android apps, it’s easy & straightforward to get an ID token, and cheap to validate on the server side. Obviously, it only works for Google accounts.
On Thu, Mar 27, 2014 at 2:40 PM, John Bradley <ve7...@ve7jtb.com> wrote: > I don't know what clients are using the play API to get 3rd party tokens. > > Perhaps Tim Bray can comment on scale of use if not specific clients. > > John B. > > On Mar 27, 2014, at 3:36 PM, Lewis Adam-CAL022 < > adam.le...@motorolasolutions.com> wrote: > > I get the idea, but I’m trying to get a feel for whether or not this model > is being built upon and to what extent. > > So if I rephrase … are there known 3rd party AS’s out there in the wild > that are consuming the Google id_token? > > Or any examples of a 3rd-party RS that is directly consuming it? > > Looking for actual examples in the wild to point to. > > adam > > *From:* John Bradley [mailto:ve7...@ve7jtb.com <ve7...@ve7jtb.com>] > *Sent:* Thursday, March 27, 2014 1:07 PM > *To:* Lewis Adam-CAL022 > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] OAuth & Enteprise federation ... 5 years from > now > > Handing out a id_token with a 3rd party AS or RS as the audience is the > standard way that Android apps that rely on Google as the source of > identity work on Android using the Google Play Services. > > This describes the API > http://android-developers.blogspot.ca/2013/01/verifying-back-end-calls-from-android.html > > On Mar 27, 2014, at 2:46 PM, Lewis Adam-CAL022 < > adam.le...@motorolasolutions.com> wrote: > > > Hi John, > > With respect to Google Play handing out id_tokens, are any there any known > instances of that being used? Either to kick of an assertion flow with > another (non-Google) AS, or to present directly to a non-Google RS? > > adam > > *From:* John Bradley [mailto:ve7...@ve7jtb.com <ve7...@ve7jtb.com>] > *Sent:* Thursday, March 27, 2014 9:07 AM > *To:* Lewis Adam-CAL022 > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] OAuth & Enteprise federation ... 5 years from > now > > Hi Adam, > > 3 is the most common today. In the Salesforce case it has the additional > benefit that when Domain 1 is federating to SalesForce via OpenID Connect > it can provide access tokens for it's API to sales force scoped for that > user for use in the SalesForce custom logic. > > 1 and 2 are similar and likely it is more of a deployment choice between > them. > We do see examples of this currently with the Android play store providing > third-party id_tokens/JWT assertions to OAuth clients. > > The reason for doing 1 or 2 vs 3 probably comes down to connivence and > security if there is an agent for the user's IdP on the device that can > act as a confidential client to the IdP for security and provide a more > consistent UI for the user. That is what we are working on in the NAPPS > WG at OIDF. > > We have examples of 1/2 now, the problem is that they are not as > universally applicable as 3 but hopefully with standardization for > developers we will se more in the next year or so. > > John B. > > On Mar 27, 2014, at 10:06 AM, Lewis Adam-CAL022 < > adam.le...@motorolasolutions.com> wrote: > > > > I am curious it ping the thoughts of others on the list of how OAuth is > going to continue to mature, especially with respect to enterprise > federation scenarios. This is something that I spend a whole lot of time > thinking about. Specifically, consider the following use case: > > An end user in domain 1 downloads a native application to access an API > exposed by domain 2, to access a protected resource in domain 2, under the > administrative control of the domain 2 enterprise. > > > There are in my mind three basic means by which OAuth can federate, which > I know I have discussed with some of you in the past: > > > > 1. First option … End user in domain 1 requests a JWT-structured > access_token from the OAuth provider in domain 1, and sends it in the HTTP > header directly to the RS in domain 2. The JWT access_token looks a whole > lot like a OIDC id_token (maybe it even is one?). The RS in domain 2 is > able to make attributed-based access control decisions based on the > contents of the JWT. This is architecturally the simplest approach, but > enterprises aren’t exactly setting up OAuth providers these days for the > intent of accessing protected resources in foreign domains. Anybody think > this might be the case 5 years from now? > > > > 2. Second option … similar to the first, but the JWT-structured > access_token from domain 1 is sent to the OAuth provider in domain 2, ala > the JWT assertion profile. Domain 1 access token is exchanged for a domain > 2 access token, and the native client uses the domain 2 access token to > send to the protected resource in domain 2. I like this slightly more than > the first option, because the resources servers in domain 2 only need to > understand the token format of their own AS. But it still suffers from the > same basic challenge of option 1, that enterprises don’t’ setup OAuth > providers today for the purpose of federating, the way that setup SAML > providers for WebSSO. > > > > 3. Third option. Native client contacts the OAuth provider in > domain 2 directly. The authorization endpoint is federation enabled > (NASCAR or other) and the user in domain 1 selects their home IdP (SAML or > OIDC) and does WebSSO to federated into the domain 2 OAuth provider. I > believe this is the model that Salesforce supports today, and it the most > tactical, since enterprise that want to federate today run out and buy a > SAML provider. > > So option 3 is the most obvious approach today. Does anybody foresee > enterprises setting up an STS in the future to federate to foreign RS’s > (the way they setup SAML providers today)? Anybody think we will see > options 1 or 2 in the future? > > > adam > _______________________________________________ > 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
