Re: [OAUTH-WG] OAuth & Enteprise federation ... 5 years from now

John Bradley <> Thu, 27 March 2014 18:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A35131A01D8 for <>; Thu, 27 Mar 2014 11:08:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id N4Ay3diCvkg8 for <>; Thu, 27 Mar 2014 11:08:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8D0601A01B5 for <>; Thu, 27 Mar 2014 11:08:10 -0700 (PDT)
Received: by with SMTP id i13so4083937qae.5 for <>; Thu, 27 Mar 2014 11:08:08 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=j0I/jkqaonJEqa+JSrIi6U7q6KuDENj+6TxmcmcWzSw=; b=Xb4ThiPA+kjQ28A1aBnXx00Yl4WiITHm3zZe62ggh+XoMA+0Pm069uUmUKq3N0L/lM QQ6giBrM7+BbWo0sacnR7+svNlnVte4rJfYRcDnWFpOCoKjwAr+B+zs+sWnKV+LBbA4A X3SZT8uyLJoEf0JCto/NMQ3sPA1kLxe/sOylueGoARljCvTIjz92/jh/Op7dRa7jWMtL xsK0vhPolYJ+v6Gw2JRsF6J2SSCmE5evwjC+RpZMpIXl7xjvIlyzhwpSl9yJvDl2+ViL hQAFMvBdZY3j04aA8tr7OnL5UYAcJy39lpDvazic4/ngAiF3Ig6fX/LdrzGeqK3JOb7r zgMA==
X-Gm-Message-State: ALoCoQmnl3IGL5gRrzAPP7KAgcAIVzE6K9dquDkdxGiV4CWWCpFnnsDz9/9atFZm+2G9ZMZhYGlZ
X-Received: by with SMTP id f9mr3865295qgf.52.1395943688057; Thu, 27 Mar 2014 11:08:08 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id u6sm5136269qaf.31.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Mar 2014 11:08:07 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_6C6CBC36-8027-4B34-A906-9D028AD7CBAF"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: John Bradley <>
In-Reply-To: <>
Date: Thu, 27 Mar 2014 15:07:10 -0300
Message-Id: <>
References: <> <> <>
To: Adam Lewis <>
X-Mailer: Apple Mail (2.1874)
Cc: "" <>
Subject: Re: [OAUTH-WG] OAuth & Enteprise federation ... 5 years from now
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Mar 2014 18:08:14 -0000

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
On Mar 27, 2014, at 2:46 PM, Lewis Adam-CAL022 <> 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 [] 
> Sent: Thursday, March 27, 2014 9:07 AM
> To: Lewis Adam-CAL022
> Cc:
> 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 <> 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