Subject: [OAUTH-WG] [token-exchange] Parameters to support external token exchange

From: Bill Burke <[email-masked]>
Date: Wed, 6 Dec 2017 16:31:20 -0500

The Keycloak project (oss idp), has implemented [1] the token exchange
draft (minus the actor token).  There's a couple of extensions we have
made to allow external token exchange to work.  I'd like to get some
consideration for these extensions to be added.  With proper
configurations, clients are able to exchange between different domains
and even social providers.  i.e. you can exchange a Facebook token for
a token issued by the IDP.

Here are the details:

We added a 'subject_issuer' parameter.  Many OAuth IDPs have opaque
access tokens and do not use JWTs for their access token (i.e.
Facebook and Google).  If the 'subject_token_type' is
'urn:ietf:params:oauth:token-type:access_token' and the access token
comes from an external provider, then the client must also pass a
'subject_issuer'.  The parameter value is something, anything that can
the IDP can resolve to an external provider.  How the validation of
this external token happens is implementation independent.

As I stated a few months back in an earlier email thread, I do not
think the 'audience' parameter would work for this type of external
exchange.  It is just too overloaded.  Additionally, I think it is
cleaner to specify an additional parameter rather than extracting
issuer information from the 'subject_token_type'.  You could do this,
but the spec would also have to define a URI scheme for
'subject_token_type' so that issuer information could be transmitted.

We also added a 'requested_issuer' parameter.  This allows the client
to request an external provider to obtain a token from.  Same reasons
and rules as 'subject_token_type'.

When 'requested_issuer' flow is done, user consent is often required
before the request issuer can issue a token for the user.  When this
is the case, a 400 response is returned with the following JSON
document:

{
   "error" : "....",
   "error_description" : "..."
   "account-link-url" : "https://...."
}

The error claim will be either token_expired or not_linked.  The
'account-link-url' claim is a link that the client can forward an user
agent to to obtain consent.  The client simply appends a
'redirect_uri' query parameter to this link and forwards the browser
for consent.  This 'redirect_uri' must be a registered and valid
redirect uri for the forwarding client.  After the redirect, the
client can then make an exchange request.  For error conditions, the
redirect_uri may by forwarded to with an additional 'error' query
parameter depending on whether the IDP deams it safe to do so.

Thanks,

Bill

[1] http://www.keycloak.org/docs/latest/securing_apps/index.html#_token-exchange

-- 
Bill Burke
Red Hat

---

From: Brian Campbell <[email-masked]>
Date: Fri, 8 Dec 2017 10:41:09 -0700

I guess I'm going to kind of restate some of what I said in that earlier
thread
<https://mailarchive.ietf.org/arch/msg/oauth/zeOPZLfocZwDo8JKqySoO00eeyM/?qid=832d65bfaf96dac039424169afa171af>
and a bit more. The access and refresh token URIs from the draft are
intended to indicate that such tokens are issued by the given authorization
server acting as the STS (perhaps this could be stated more clearly in the
doc). As such, there isn't direct explicit support for OAuth access token
to OAuth access token cross-domain type exchanges. That was intentional and
I think is appropriate as I don't believe this draft should delve into
pseudo federating access tokens and all the additional complexity and
security implications that entails. The assertion based authorization
grants (RFCs 7523 <https://tools.ietf.org/html/rfc7523> & 7522
<https://tools.ietf.org/html/rfc7522>) are intended to facilitate acquiring
an access token from an external or cross-domain AS and I prefer that more
explicit model for cross-domain than codifying a rather implicit way of
doing it in token exchange. A Facebook access token, for example, is issued
to a client for delegated access to Facebook APIs. It isn't for delegated
access to some other domain's APIs but an access token for access token
exchange effectively turns it into that. And in some situations that can
have problematic security implications. Big providers like Facebook have a
lot of apps (OAuth clients) that can get access tokens. An organization
might well be okay with an app it controls exchanging a Facebook access
token for an access token for its own APIs. But a 3rd party Facebook app
(like maybe a new viral rate my '80's hairdo app) doing the same thing
could be very problematic. It's not exactly the same thing but many of the
same potential issues arise as when using OAuth for User Authentication
<https://oauth.net/articles/authentication/>. Standardization around access
token for access token exchange would, at a minimum, need some real
security analysis and recommendations/considerations.

The token exchange draft went thought WGLC some time ago and is currently
being written up by the document shepherd to send to the AD. It's close.
It's been a long time coming and I'd really object to derailing it by
making big additions to it at this late stage in the process.

If explicit support for directly swapping an access token from one AS for
an access token issued by a different AS is something this WG is interested
in working on, while admittedly I have my hesitations, I propose/suggest
that it be done in a new document. Such a document could but wouldn't
necessarily have to take the from of the additional extension parameters
you've mentioned. It could, for example, be a 'token profile' of sorts that
defines a new URI with an associated format that is some simple structure
that carries both the access token and issuer together. Something like
"urn:ietf:params:oauth:token-type:wrapped_foreign_access_token" and
{"issuer":"https://api.login.yahoo.com","token":"bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2"}
- that's just spitballing but hopefully conveys the idea. The new document
would also have to cover the security considerations.

On Wed, Dec 6, 2017 at 2:31 PM, Bill Burke <[email-masked]> wrote:

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

-- 
*CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you.*

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Fri, 8 Dec 2017 13:31:55 -0500

Hi Bill,

I agree with Brian that an AS to AS token exchange is beyond the scope of
this document.
I suggest that you send a separate email to start a discussion on this
topic and see if there is interest in the WG to take this topic as a new
work.

Regards,
 Rifaat (as co-chair and document shepherd)

On Fri, Dec 8, 2017 at 12:41 PM, Brian Campbell <[email-masked]>
wrote:

> <https://tools.ietf.org/html/rfc7522>) are intended to facilitate
> acquiring an access token from an external or cross-domain AS and I prefer
> that more explicit model for cross-domain than codifying a rather implicit
> way of doing it in token exchange. A Facebook access token, for example, is
> issued to a client for delegated access to Facebook APIs. It isn't for
> delegated access to some other domain's APIs but an access token for access
> token exchange effectively turns it into that. And in some situations that
> can have problematic security implications. Big providers like Facebook
> have a lot of apps (OAuth clients) that can get access tokens. An
> organization might well be okay with an app it controls exchanging a
> Facebook access token for an access token for its own APIs. But a 3rd party
> Facebook app (like maybe a new viral rate my '80's hairdo app) doing the
> same thing could be very problematic. It's not exactly the same thing but
> many of the same potential issues arise as when using OAuth for User
> Authentication <https://oauth.net/articles/authentication/>.
> Standardization around access token for access token exchange would, at a
> minimum, need some real security analysis and recommendations/considerations.
>
>
> {"issuer":"https://api.login.yahoo.com","token":"bwcK0esc3AC
> C3DB2Y5_lESsXE8o9ltc05O89jdN-dg2"} - that's just spitballing but
> hopefully conveys the idea. The new document would also have to cover the
> security considerations.
>
>
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*

---

From: Mike Jones <[email-masked]>
Date: Fri, 8 Dec 2017 20:05:55 +0000

I also agree that this additional functionality is out of scope for the Token Exchange specification.

-- Mike
________________________________
From: OAuth <[email-masked]> on behalf of Rifaat Shekh-Yusef <[email-masked]>
Sent: Friday, December 8, 2017 1:31:55 PM
To: Brian Campbell
Cc: OAuth WG
Subject: Re: [OAUTH-WG] [token-exchange] Parameters to support external token exchange

Hi Bill,

I agree with Brian that an AS to AS token exchange is beyond the scope of this document.
I suggest that you send a separate email to start a discussion on this topic and see if there is interest in the WG to take this topic as a new work.

Regards,

On Fri, Dec 8, 2017 at 12:41 PM, Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:
I guess I'm going to kind of restate some of what I said in that earlier thread<https://mailarchive.ietf.org/arch/msg/oauth/zeOPZLfocZwDo8JKqySoO00eeyM/?qid=832d65bfaf96dac039424169afa171af> and a bit more. The access and refresh token URIs from the draft are intended to indicate that such tokens are issued by the given authorization server acting as the STS (perhaps this could be stated more clearly in the doc). As such, there isn't direct explicit support for OAuth access token to OAuth access token cross-domain type exchanges. That was intentional and I think is appropriate as I don't believe this draft should delve into pseudo federating access tokens and all the additional complexity and security implications that entails. The assertion based authorization grants (RFCs 7523<https://tools.ietf.org/html/rfc7523> & 7522<https://tools.ietf.org/html/rfc7522>) are intended to facilitate acquiring an access token from an external or cross-domain AS and I prefer that more explicit model for cross-domain than codifying a rather implicit way of doing it in token exchange. A Facebook access token, for example, is issued to a client for delegated access to Facebook APIs. It isn't for delegated access to some other domain's APIs but an access token for access token exchange effectively turns it into that. And in some situations that can have problematic security implications. Big providers like Facebook have a lot of apps (OAuth clients) that can get access tokens. An organization might well be okay with an app it controls exchanging a Facebook access token for an access token for its own APIs. But a 3rd party Facebook app (like maybe a new viral rate my '80's hairdo app) doing the same thing could be very problematic. It's not exactly the same thing but many of the same potential issues arise as when using OAuth for User Authentication<https://oauth.net/articles/authentication/>. Standardization around access token for access token exchange would, at a minimum, need some real security analysis and recommendations/considerations.

The token exchange draft went thought WGLC some time ago and is currently being written up by the document shepherd to send to the AD. It's close. It's been a long time coming and I'd really object to derailing it by making big additions to it at this late stage in the process.

If explicit support for directly swapping an access token from one AS for an access token issued by a different AS is something this WG is interested in working on, while admittedly I have my hesitations, I propose/suggest that it be done in a new document. Such a document could but wouldn't necessarily have to take the from of the additional extension parameters you've mentioned. It could, for example, be a 'token profile' of sorts that defines a new URI with an associated format that is some simple structure that carries both the access token and issuer together. Something like "urn:ietf:params:oauth:token-type:wrapped_foreign_access_token" and {"issuer":"https://api.login.yahoo.com","token":"bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2"} - that's just spitballing but hopefully conveys the idea. The new document would also have to cover the security considerations.

On Wed, Dec 6, 2017 at 2:31 PM, Bill Burke <[email-masked]<mailto:[email-masked]>> wrote:

Here are the details:

{
   "error" : "....",

Thanks,

Bill

--
Bill Burke
Red Hat

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

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Bill Burke <[email-masked]>
Date: Fri, 8 Dec 2017 16:29:39 -0500

On Fri, Dec 8, 2017 at 12:41 PM, Brian Campbell
<[email-masked]> wrote:
> thread and a bit more. The access and refresh token URIs from the draft are
> doc). As such, there isn't direct explicit support for OAuth access token to
> OAuth access token cross-domain type exchanges. That was intentional and I
> think is appropriate as I don't believe this draft should delve into pseudo
> federating access tokens and all the additional complexity and security
> implications that entails.

I'll look in my email archives again, but, I wasn't convinced then
that there is all this additional complexity.

> The assertion based authorization grants (RFCs
> 7523 & 7522) are intended to facilitate acquiring an access token from an
> external or cross-domain AS and I prefer that more explicit model for
> cross-domain than codifying a rather implicit way of doing it in token
> exchange.

Not understanding what you mean by implicit vs. explicit.  I don't see
how what we've implemented is any more implicit than the current
specification.  If anything, I thought our impl was more explicit as
you can't derive the issuer from an opaque access token in the current
spec.

> A Facebook access token, for example, is issued to a client for
> delegated access to Facebook APIs. It isn't for delegated access to some
> other domain's APIs but an access token for access token exchange
> effectively turns it into that. And in some situations that can have
> problematic security implications.

Internet applications trust Facebook, Google, whoever to identity and
authenticate users all the time and to grant access and permission
based on that identity.  An external exchange is just a non-browser
mechanism to facilitate this relationship.  For our IDP, our userbase
often use us as a broker between the various social websites and their
apps.  This way, apps don't care where the user was authenticated
from, they just see open id connect with a token format and domain
they control.  Developers often have apps that they are not able to
change how a user logs in or cannot unify their apps with a common
STS, token format, or even protocol.  Yet they still have a need to
make secure invocations across these domains and apps.

> Big providers like Facebook have a lot of
> apps (OAuth clients) that can get access tokens. An organization might well
> be okay with an app it controls exchanging a Facebook access token for an
> access token for its own APIs. But a 3rd party Facebook app (like maybe a
> new viral rate my '80's hairdo app) doing the same thing could be very
> problematic. It's not exactly the same thing but many of the same potential
> issues arise as when using OAuth for User Authentication. Standardization
> around access token for access token exchange would, at a minimum, need some
> real security analysis and recommendations/considerations.
>
> It's been a long time coming and I'd really object to derailing it by making
> big additions to it at this late stage in the process.
>

That's fair enough.  I didn't know how far in the process the token
exchange draft was.  In the least, I wanted to make the WG aware of
our work.  We have a decent and growing user base with a problem
looking for a solution and we're going to get a lot of feedback on
what we've implemented.   At least from our open source project
perspective, there's a lot more interest in external exchange than
internal.  Which is why I'm posting this.

-- 
Bill Burke
Red Hat

---

From: Brian Campbell <[email-masked]>
Date: Mon, 11 Dec 2017 16:23:29 -0700

The words implicit vs. explicit might not have been the best choice but the
concepts are complicated and subtle and I was (and still am) at a bit of a
lose for the right language to describe things.

By explicit what I was trying to express is that the token that is going
cross-domain is explicitly intended for that purpose and includes things
like an audience restriction that reflect that intention. The OpenID
Connect ID Token is an example of that for browser based flows and the RFC
7523 JWT authorization grant is an example for non-browser flows.

By implicit what I was trying to express are situations where a token that
issued for a particular purpose (like a Facebook access token for access to
Facebook APIs) is used implicitly for a different purpose (like getting a
different access token for access to APIs in a different domain).

On Fri, Dec 8, 2017 at 2:29 PM, Bill Burke <[email-masked]> wrote:

> making

---

From: Bill Burke <[email-masked]>
Date: Tue, 12 Dec 2017 13:19:06 -0500

How the target STS processes the external token is up to the STS.  The
external token could solely be used as an authentication mechanism.
The client must be registered and known by the STS, so it can decide
if the client is allowed to exchange an external token, and what
target audience or resource the client is allowed to ask for.  At
least this is how it works in our implementation.  With Facebook
token, the STS knows that it is a Facebook token and was obtained to
access Facebook APIs.  I don't see the vulnerabilites right now as
much different than an internal exchange or bearer token invocations.
 Clients need to be aware that they should downgrade tokens before
passing them to less trusted target endpoints.

On Mon, Dec 11, 2017 at 6:23 PM, Brian Campbell
<[email-masked]> wrote:
> like an audience restriction that reflect that intention. The OpenID Connect
> ID Token is an example of that for browser based flows and the RFC 7523 JWT
> authorization grant is an example for non-browser flows.
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
> computer. Thank you.

-- 
Bill Burke
Red Hat