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

Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> Fri, 08 December 2017 18:31 UTC

Return-Path: <rifaat.ietf@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F35951289B0 for <oauth@ietfa.amsl.com>; Fri, 8 Dec 2017 10:31:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HlHhVaL51jo1 for <oauth@ietfa.amsl.com>; Fri, 8 Dec 2017 10:31:57 -0800 (PST)
Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03DB5127601 for <oauth@ietf.org>; Fri, 8 Dec 2017 10:31:57 -0800 (PST)
Received: by mail-ua0-x22e.google.com with SMTP id v20so8093907uaj.0 for <oauth@ietf.org>; Fri, 08 Dec 2017 10:31:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.176.22.82 with SMTP id l18mr18206679uae.73.1512757916028; Fri, 08 Dec 2017 10:31:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.68.133 with HTTP; Fri, 8 Dec 2017 10:31:55 -0800 (PST)
In-Reply-To: <CA+k3eCS0YexwKEBVLXRkqdwpfgcr8aseTtmFe=D=BXF_JofXLA@mail.gmail.com>
References: <CABRXCmwBV+OxxihkK31sDzBZbaTDP3XFvpdL=_ekreO1N_gy_g@mail.gmail.com> <CA+k3eCS0YexwKEBVLXRkqdwpfgcr8aseTtmFe=D=BXF_JofXLA@mail.gmail.com>
From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Date: Fri, 8 Dec 2017 13:31:55 -0500
Message-ID: <CAGL6epJv+98xSXezfSEMvoY3CHANZy0d_NKsK0HZbi7fAehgJA@mail.gmail.com>
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: Bill Burke <bburke@redhat.com>, OAuth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="001a11456b30375413055fd8664c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/_0_juYtPWZ7MY_EA2BlKq5WWPXo>
Subject: Re: [OAUTH-WG] [token-exchange] Parameters to support external token exchange
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=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
work.

Regards,
 Rifaat (as co-chair and document shepherd)

On Fri, Dec 8, 2017 at 12:41 PM, Brian Campbell <bcampbell@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 <bburke@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
>
>