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

From: Lewis Adam-CAL022 <[email-masked]>
Date: Thu, 27 Mar 2014 13:06:45 +0000

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

---

From: Paul Madsen <[email-masked]>
Date: Thu, 27 Mar 2014 09:29:48 -0400

Hi Adam, we are confronting this issue in the NAPPS effort and are 
exploring a model that resembles your Option 2

The Token Agent (TA) obtains an id-token from the first AS1, this 
targetted at the second AS2 (the one local to the target RS). The TA 
then exchanges that id_token at AS2 for an access token that the RS will 
be able to validate

Option 3 is indeed today's default for layering federation onto OAuth

paul

On 3/27/14, 9: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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: John Bradley <[email-masked]>
Date: Thu, 27 Mar 2014 11:06:48 -0300

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 <[email-masked]> wrote:

> 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.
> 
> 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

---

From: Paul Madsen <[email-masked]>
Date: Thu, 27 Mar 2014 10:14:56 -0400

a variant I've seen proposed is to to have

1) the native app obtain tokens from AS1
2) the RS only accept tokens from AS2
3) have AS1 request tokens of AS2 on back-channel to meet reqs of #1 & #2

lots of ways to 'close the loop'

paul

On 3/27/14, 10:06 AM, John Bradley wrote:
> 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.
>
> 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 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> 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?
>>
>> 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.
>> RS's (the way they setup SAML providers today)?  Anybody think we 
>> will see options 1 or 2 in the future?
>> adam
>> [email-masked] <mailto:[email-masked]>

---

From: Lewis Adam-CAL022 <[email-masked]>
Date: Thu, 27 Mar 2014 17:46:29 +0000

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:[email-masked]]
Sent: Thursday, March 27, 2014 9:07 AM
To: Lewis Adam-CAL022
Cc: [email-masked]
Subject: Re: [OAUTH-WG] OAuth & Enteprise federation ... 5 years from now

Hi Adam,

John B.

On Mar 27, 2014, at 10:06 AM, Lewis Adam-CAL022 <[email-masked]<mailto:[email-masked]>> wrote:

adam
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: John Bradley <[email-masked]>
Date: Thu, 27 Mar 2014 15:07:10 -0300

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

---

From: Lewis Adam-CAL022 <[email-masked]>
Date: Thu, 27 Mar 2014 18:36:13 +0000

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:[email-masked]]
Sent: Thursday, March 27, 2014 1:07 PM
To: Lewis Adam-CAL022
Cc: [email-masked]
Subject: Re: [OAUTH-WG] OAuth & Enteprise federation ... 5 years from now

On Mar 27, 2014, at 2:46 PM, Lewis Adam-CAL022 <[email-masked]<mailto:[email-masked]>> wrote:

Hi John,

adam

From: John Bradley [mailto:[email-masked]]
Sent: Thursday, March 27, 2014 9:07 AM
To: Lewis Adam-CAL022
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] OAuth & Enteprise federation ... 5 years from now

Hi Adam,

John B.

adam

---

From: George Fletcher <[email-masked]>
Date: Thu, 27 Mar 2014 15:37:36 -0400

Hi Adam,

Don't know if it qualifies, but we use option 1 with a partner and our 
Instant Message service. The client obtains a token from the partner AS 
and presents it to the IM RS which validates it and provides access to 
the service. This process is not restricted to that partner in anyway, 
but the JWS is unique to our implementation.

Thanks,
George

On 3/27/14, 2:36 PM, Lewis Adam-CAL022 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 3^rd -party RS that is directly consuming it?
>
> *From:*John Bradley [mailto:[email-masked]]
> *Sent:* Thursday, March 27, 2014 1:07 PM
> *To:* Lewis Adam-CAL022
> *Cc:* [email-masked]
> *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 
> 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:[email-masked]]
> *Sent:*Thursday, March 27, 2014 9:07 AM
> *To:*Lewis Adam-CAL022
> *Cc:[email-masked] <mailto:[email-masked]>
> *Subject:*Re: [OAUTH-WG] OAuth & Enteprise federation ... 5 years from now
>
> Hi Adam,
>

-- 
George Fletcher <http://connect.me/gffletch>

---

From: John Bradley <[email-masked]>
Date: Thu, 27 Mar 2014 18:40:43 -0300

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 <[email-masked]> 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? 
>

---

From: Tim Bray <[email-masked]>
Date: Thu, 27 Mar 2014 14:47:45 -0700

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 <[email-masked]> wrote:

> *From:* John Bradley [mailto:[email-masked] <[email-masked]>]
> *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
> 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:[email-masked] <[email-masked]>]
> *Sent:* Thursday, March 27, 2014 9:07 AM
> *To:* Lewis Adam-CAL022
> *Cc:* [email-masked]
> *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.
>
> We do see examples of this currently with the Android play store providing
> third-party id_tokens/JWT assertions to OAuth clients.
>
> 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.
>
>  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.
>
> 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

---

From: Lewis Adam-CAL022 <[email-masked]>
Date: Thu, 27 Mar 2014 22:04:17 +0000

So the Google AS is doing for the RS what an IdP typically does for a third-party SP.  Interesting.  This is a pattern that I have thought useful in the past.

I recall at CIS last year Vittorio mentioning that the Azure OAuth AS was also putting that option out there as well, to see what RS’s might pick up on it.

Glad to know that is actually seeing some traction.

It’s not quite as flexible as using the id_token in the assertion flow to a 3rd-party AS since Google or Azure (or other) can’t know about scopes of third party RS, but it also enables smaller RS providers to pickup OAuth without having to deploy their own AS.

Now it would be interesting if Google or Azure or somebody else stood up an AS that enabled third-party AS’s to configure their own scopes on it.  Authorization Server as a Service (ASaaS), anybody?  :-)

Will be interesting to see how this all plays out …

adam

From: Tim Bray [mailto:[email-masked]]
Sent: Thursday, March 27, 2014 4:48 PM
To: John Bradley
Cc: Lewis Adam-CAL022; [email-masked]
Subject: Re: [OAUTH-WG] OAuth & Enteprise federation ... 5 years from now

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 <[email-masked]<mailto:[email-masked]>> wrote:
I don't know what clients are using the play API to get 3rd party tokens.

John B.

On Mar 27, 2014, at 3:36 PM, Lewis Adam-CAL022 <[email-masked]<mailto:[email-masked]>> wrote:

adam

Hi John,

adam

Hi Adam,

John B.

adam