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

Bill Burke <bburke@redhat.com> Wed, 06 December 2017 21:31 UTC

Return-Path: <bburke@redhat.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 5D08A1270AC for <oauth@ietfa.amsl.com>; Wed, 6 Dec 2017 13:31:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.421
X-Spam-Status: No, score=-1.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 3ornRe46XZQY for <oauth@ietfa.amsl.com>; Wed, 6 Dec 2017 13:31:22 -0800 (PST)
Received: from mail-ua0-f178.google.com (mail-ua0-f178.google.com []) (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 7F9721200FC for <oauth@ietf.org>; Wed, 6 Dec 2017 13:31:22 -0800 (PST)
Received: by mail-ua0-f178.google.com with SMTP id j14so3884544uag.11 for <oauth@ietf.org>; Wed, 06 Dec 2017 13:31:22 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=SsHrGDpuGt3R6goxSLMXqvF1IPIxb7pIJti7LktiRxw=; b=ICLrrTKLR3qcPC3RCUzIdQpOq6F1nzJyi+qFTqbXgsfQhDj0YtyIapWH4q2frjIgqk T1JuYwhcXz1E2BjFMmlezxbg2NIhJ/l2zCluFbWXrYZN/0f8h0rr2L32UDQ0I6LpRHoo 7cip7xBTFnYYfoNuZ4L6A1C6cpqDsTWUOUCAsLGtqeauIFhHVhPI3xhVwKDXAKIrSWZd b1A8JWfSpGWm0Pc8VEc72pJoQ7Hd+52e6xj94sI1HwAX4kLp5+2Meg7pAzCgeIpGRJj6 i9iEZORIQC0WuMIgctgZocHyHYa52iX35/DjnCsHid/W+gOx8wHezveSsY/lBeshjqvd oB8Q==
X-Gm-Message-State: AKGB3mJPJlpM2vqNfMorjYufgq8ab4awLrDIXgCwJg/e8pwirhhANd/y wnzv+JPxAlPHIf9i0WctxxwXZJk3/LuldcO8fvkwf2BF
X-Google-Smtp-Source: AGs4zMYHme6poqy0Cnc44/j5xjKE/IWgpr3asEtSymT1o+omW1RJrJAhjIWDq6aknrUlNa3iW5oSW1ilDFqb4FbxuEg=
X-Received: by with SMTP id x9mr11447762uac.76.1512595881087; Wed, 06 Dec 2017 13:31:21 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 6 Dec 2017 13:31:20 -0800 (PST)
From: Bill Burke <bburke@redhat.com>
Date: Wed, 6 Dec 2017 16:31:20 -0500
Message-ID: <CABRXCmwBV+OxxihkK31sDzBZbaTDP3XFvpdL=_ekreO1N_gy_g@mail.gmail.com>
To: OAuth WG <oauth@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Vt4_jPowGgQXhbebVEq0dJ7SoL0>
Subject: [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: Wed, 06 Dec 2017 21:31:24 -0000

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

   "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.



[1] http://www.keycloak.org/docs/latest/securing_apps/index.html#_token-exchange

Bill Burke
Red Hat