Re: [OAUTH-WG] OAuth & Enteprise federation ... 5 years from now
Tim Bray <tbray@textuality.com> Thu, 27 March 2014 21:48 UTC
Return-Path: <tbray@textuality.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1459D1A06DA for <oauth@ietfa.amsl.com>; Thu, 27 Mar 2014 14:48:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVM0BznuMZYs for <oauth@ietfa.amsl.com>; Thu, 27 Mar 2014 14:48:07 -0700 (PDT)
Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF1B1A03DA for <oauth@ietf.org>; Thu, 27 Mar 2014 14:48:07 -0700 (PDT)
Received: by mail-vc0-f175.google.com with SMTP id lh14so4964530vcb.6 for <oauth@ietf.org>; Thu, 27 Mar 2014 14:48:05 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=E9CoBgkt5/uWO0BRihwJrDg08jtB5nafmZ9CLlD7Fpg=; b=U2cl/gOOWHd+es9RsLYxm6e6bYsUL7xpFFc5TBSvi24payPTrPx9Uf482We0YbGZYA hMQlgegDh7gxMHofE7KreVKHppjM19/8l0eWx2X9kR/puDsIILQrm5M/9BKci/5QMVDR nMWFQLyq+4UJ01HqM0g8kpfopoZNQ4vwZoxllinLu7R7q/H3woxs4gXMyRO66fGN9YPz FrPpC9LreihrYaveRUxEkSI8xNDyUIdQLW6R5P1ebiMfBJgkHjWg7mnuA6TYjhZt4JH3 LDgIY4IOp/GbUGaTWrpHNQZu0QR3WONG2w6jEDv1b5ligLOPQnJ8movV2+34Ta5niH+i i3bA==
X-Gm-Message-State: ALoCoQn1I94LV3+2t3XqA54p9X9SXrZJR8fHayg3pvhn8C+DMq8HRsOzRscD19BcVVZdJEsxG7Mu
X-Received: by 10.58.195.202 with SMTP id ig10mr491812vec.33.1395956885496; Thu, 27 Mar 2014 14:48:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.98.73 with HTTP; Thu, 27 Mar 2014 14:47:45 -0700 (PDT)
X-Originating-IP: [96.49.81.176]
In-Reply-To: <C082266B-009B-481D-9224-7B1A05F2397F@ve7jtb.com>
References: <c174791bb42e462d813b62a952ded267@DM2PR04MB735.namprd04.prod.outlook.com> <F9D7698F-9713-477D-9D14-BF97425CFF92@ve7jtb.com> <4fa46e94eca54ce0940162f8ef4101dd@DM2PR04MB735.namprd04.prod.outlook.com> <C300A03E-CDCB-48BF-B2A2-E519E017669E@ve7jtb.com> <2a2d0cadd4d445a9b148c8a2a6e06dc3@DM2PR04MB735.namprd04.prod.outlook.com> <C082266B-009B-481D-9224-7B1A05F2397F@ve7jtb.com>
From: Tim Bray <tbray@textuality.com>
Date: Thu, 27 Mar 2014 14:47:45 -0700
Message-ID: <CAHBU6itVGTZoCqJ2F4ezwcTcxzAwMdBBTOzJ5LgcjDYrLpU0nw@mail.gmail.com>
To: John Bradley <ve7jtb@ve7jtb.com>
Content-Type: multipart/alternative; boundary="047d7b66fce74841ba04f59d8a0e"
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/RBSq2SVEL9lhhyXJD1hy4baR3qA
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth & Enteprise federation ... 5 years from now
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Mar 2014 21:48:11 -0000
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 <ve7jtb@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.Lewis@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:ve7jtb@ve7jtb.com <ve7jtb@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.Lewis@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:ve7jtb@ve7jtb.com <ve7jtb@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.Lewis@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-WG] OAuth & Enteprise federation ... 5 yea… Lewis Adam-CAL022
- Re: [OAUTH-WG] OAuth & Enteprise federation ... 5… Paul Madsen
- Re: [OAUTH-WG] OAuth & Enteprise federation ... 5… John Bradley
- Re: [OAUTH-WG] OAuth & Enteprise federation ... 5… Paul Madsen
- Re: [OAUTH-WG] OAuth & Enteprise federation ... 5… Lewis Adam-CAL022
- Re: [OAUTH-WG] OAuth & Enteprise federation ... 5… John Bradley
- Re: [OAUTH-WG] OAuth & Enteprise federation ... 5… Lewis Adam-CAL022
- Re: [OAUTH-WG] OAuth & Enteprise federation ... 5… George Fletcher
- Re: [OAUTH-WG] OAuth & Enteprise federation ... 5… John Bradley
- Re: [OAUTH-WG] OAuth & Enteprise federation ... 5… Tim Bray
- Re: [OAUTH-WG] OAuth & Enteprise federation ... 5… Lewis Adam-CAL022