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> 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":"bwcK0esc3AC > C3DB2Y5_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 > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
