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

[Mike Jones <[e-mail]>]

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

-- Mike
________________________________
From: OAuth <[e-mail]> on behalf of Rifaat Shekh-Yusef <[e-mail]>
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,
 Rifaat (as co-chair and document shepherd)

On Fri, Dec 8, 2017 at 12:41 PM, Brian Campbell <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> wrote:
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

_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth