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