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> 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
> 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
https://www.ietf.org/mailman/listinfo/oauth
