I also agree that this additional functionality is out of scope for the Token Exchange specification.
-- Mike ________________________________ From: OAuth <oauth-boun...@ietf.org> on behalf of Rifaat Shekh-Yusef <rifaat.i...@gmail.com> 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 <bcampb...@pingidentity.com<mailto:bcampb...@pingidentity.com>> 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 <bbu...@redhat.com<mailto:bbu...@redhat.com>> 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 OAuth@ietf.org<mailto:OAuth@ietf.org> 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 OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
