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

Rifaat Shekh-Yusef <> Fri, 08 December 2017 18:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F35951289B0 for <>; Fri, 8 Dec 2017 10:31:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HlHhVaL51jo1 for <>; Fri, 8 Dec 2017 10:31:57 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c08::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 03DB5127601 for <>; Fri, 8 Dec 2017 10:31:57 -0800 (PST)
Received: by with SMTP id v20so8093907uaj.0 for <>; Fri, 08 Dec 2017 10:31:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9hKmyr24bKxTB1Mv8DW4kSw8jmIg8BnwWvmDxc0mkAo=; b=jwe8gxg7OE57xOoAtwQsy4e/gADMu8Mtzd7M/9jrcBE6y6Wil187LXXP/OeF9K5ssD 3V2WDO3qNqFafivq8eBPmjp2PVuCQs+3LwoRowohTcxAsjxSe4pZAdfXl7cMcbY7B0Bi JHhwwH9UHPpeKAmK9YJVTOZd/tjj9SILu3AX4Jjpn+2JQY23/Rl0rpZLHZcF36XWtNQH rDuIUKpIs8rzu7eJV6XekcO/YlJv0Da6RTG0/oIPb8QahhYi8VgsyoaeMD/Xc5KeLAx/ rSQrTb4QSY8o0uDnikDuKPQdCOxaLADFWqxL4ejrR2oD7hmB/ZgA6rRzVc4dBTodzJ0s 6t6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9hKmyr24bKxTB1Mv8DW4kSw8jmIg8BnwWvmDxc0mkAo=; b=cOIE4Ay3hYfplhQnUm55ohsxwSeORqozS6Pqn5x6m9j+fGa9TxwzbYcGWKDJ+swCj0 aU/Fs4TkLXQgicy+q0EOhvrm15dNMGdpO21slDp+3Ga4IdqnSC0Gffky0emzEyjy59QD 8BxAvbVWfbfRm32P8HqFqQ7a2FKmneelZ8F+zOfzhdpksmECcu5CvbRqR2qWdMbrVKRU 0HceYNGd8K5D9kP6FklMk4OEjSw7dfoLYXklzvZxi3DPi1feq3vFWuTntDIl6FDRppNS jZXL0J9MjyYeCITuoydLSmlMVgSmUbfUFHjodUVO/b6l7owaCfYVuJnmO3oEFgk1ctfc wFww==
X-Gm-Message-State: AKGB3mIEr9bAdTeaMhB13iPYvbnzE25Y6PPCPV7alsNGPxIhmsWtLLHm pgGYjq5nG0WLKnui9hMCPltwwgL85jFSyOQPo1E=
X-Google-Smtp-Source: AGs4zMZrQCZHIsgS94uFh0Uy1Xrh3BuqfdRMeIld9dcdKuoOgEXDYcdh4OvE1vcp9t5nBSJNMB7Sx8dpbY2dSQBrkPY=
X-Received: by with SMTP id l18mr18206679uae.73.1512757916028; Fri, 08 Dec 2017 10:31:56 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 8 Dec 2017 10:31:55 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Rifaat Shekh-Yusef <>
Date: Fri, 8 Dec 2017 13:31:55 -0500
Message-ID: <>
To: Brian Campbell <>
Cc: Bill Burke <>, OAuth WG <>
Content-Type: multipart/alternative; boundary="001a11456b30375413055fd8664c"
Archived-At: <>
Subject: Re: [OAUTH-WG] [token-exchange] Parameters to support external token exchange
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 08 Dec 2017 18:32:00 -0000

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

 Rifaat (as co-chair and document shepherd)

On Fri, Dec 8, 2017 at 12:41 PM, Brian Campbell <>

> I guess I'm going to kind of restate some of what I said in that earlier
> thread
> <>
> 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 <> & 7522
> <>) 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 <>.
> 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":"","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 <> 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]
>> #_token-exchange
>> --
>> Bill Burke
>> Red Hat
>> _______________________________________________
>> OAuth mailing list
> *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