Subject: [OAUTH-WG] OAuth Token Swap (token chaining)

From: Justin Richer <[email-masked]>
Date: Mon, 23 Mar 2015 14:40:33 -0500

As mentioned in today’s IETF meeting, here are the two drafts dealing with generic token swap:

https://tools.ietf.org/html/draft-hunt-oauth-chain-01
https://tools.ietf.org/html/draft-richer-oauth-chain-00

---

From: Brian Campbell <[email-masked]>
Date: Tue, 24 Mar 2015 07:55:10 -0500

And here's the somewhat different take on token exchange that I mentioned
yesterday:
https://tools.ietf.org/html/draft-campbell-oauth-sts-01

A little more background, context, and discussion about it can be seen
following the thread on the Call for Adoption of "OAuth 2.0 Token Exchange"
as an OAuth WG Item:
https://www.ietf.org/mail-archive/web/oauth/current/msg13236.html
https://www.ietf.org/mail-archive/web/oauth/current/msg13305.html
... etc ...
https://www.ietf.org/mail-archive/web/oauth/current/msg13311.html
... etc.

On Mon, Mar 23, 2015 at 2:40 PM, Justin Richer <[email-masked]> wrote:

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

---

From: Bill Burke <[email-masked]>
Date: Tue, 24 Mar 2015 09:42:10 -0400

On 3/24/2015 8:55 AM, Brian Campbell wrote:
> And here's the somewhat different take on token exchange that I
> mentioned yesterday:

I'm unclear how your STS would work.  Is your client required to go 
through the whole OAuth process to obtain an access token on behalf of 
the user before it can invoke on the STS?  Or can it be granted tokens 
for any user out of band without user consent or user authorization?

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

---

From: Phil Hunt <[email-masked]>
Date: Tue, 24 Mar 2015 08:43:17 -0500

As the original author, I don't know why this issue has not been followed through on. Still it has given me about 3 years to reflect. :-)

I support any of these drafts going forward but I think we have to think through performance issues. 

I concluded that a swap should only be done, if at all, when an edge server wants to access a foreign domain as the inbound AT may be opaque. Otherwise passing the original AT in another header plus a service token for the edge server in the authentication header might be more scalable. The edge server token is long-lived and the same-domain internal server can parse or introspect both tokens to understand actas etc.  in either method the authenticated context carries the primary security credential.  

For the internal case, the value of a token swipe is lost since consent is implicit and probably does not need to be double-checked each time. 

Phil

> On Mar 24, 2015, at 07:55, Brian Campbell <[email-masked]> wrote:
> 
> And here's the somewhat different take on token exchange that I mentioned yesterday:
> A little more background, context, and discussion about it can be seen following the thread on the Call for Adoption of "OAuth 2.0 Token Exchange" as an OAuth WG Item: