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

Bill Burke <bburke@redhat.com> Fri, 08 December 2017 21:29 UTC

Return-Path: <bburke@redhat.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 DF6AD12711E for <oauth@ietfa.amsl.com>; Fri, 8 Dec 2017 13:29:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 2qywAIbknECP for <oauth@ietfa.amsl.com>; Fri, 8 Dec 2017 13:29:41 -0800 (PST)
Received: from mail-ua0-f181.google.com (mail-ua0-f181.google.com [209.85.217.181]) (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 91509124B18 for <oauth@ietf.org>; Fri, 8 Dec 2017 13:29:41 -0800 (PST)
Received: by mail-ua0-f181.google.com with SMTP id i4so8347476uab.5 for <oauth@ietf.org>; Fri, 08 Dec 2017 13:29:41 -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:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aSl0taKZ2iL0Z2ERVsWnyoKVsB9eYJcX/haY/kj+agw=; b=pmwKcO8RNfx6Mtt6chPuRwnzeFQ3H5xt7sR8I7pTOg260t8OiLjpxgxe66uwaobe+p DjdczTY2K1SOZSWt2wj/0JEaxxaTueG5FX27cyK2K08/VAARs1zpGIdxsDfU3fShGOwC VasKWw2tRmkVDosdNUdAfcDcyQtQCQmXgy6l5T5aaBCIj3sDIv+HnZjyhhG/nwLyqAhG dFDLP5LFCSK62Ab6wUYVd3cxs4aEcjtOuSU51JDMkcalDP5/kfWSaaU/C88QLSh2oa1a K1MxS6BlhKfSYd5cg+22DJ6w1TLz37151pAKxh+T9+Frl0r0fNbWh1xsihzPaXZ5Ks8w rIMw==
X-Gm-Message-State: AKGB3mKLn7TF6owkeFFkILL6mG+7jfumM+sabmCC8a0VSQOgoT4RaFZI ckhwuEt7OQDY0dKv/TpzauriASL9+2h0jsE1paFrKg==
X-Google-Smtp-Source: AGs4zMalTapREaCUO7of83R396u9GvOsyyhq2mmpxcBVokdH69oKVTdBqZDXrHB8xhe92qGDpgnO9qMvU2VOqpOIgkE=
X-Received: by 10.176.23.81 with SMTP id k17mr8636933uaf.131.1512768580469; Fri, 08 Dec 2017 13:29:40 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.68.86 with HTTP; Fri, 8 Dec 2017 13:29:39 -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: Bill Burke <bburke@redhat.com>
Date: Fri, 8 Dec 2017 16:29:39 -0500
Message-ID: <CABRXCmzy48wR3Q5MrGnsbZh6AQbAW_5Lrd8zstqBnk+Q1XMEsA@mail.gmail.com>
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: OAuth WG <oauth@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/IhoWCEE66foE_0AI2zTzjMJvQP4>
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 21:29:44 -0000

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

I'll look in my email archives again, but, I wasn't convinced then
that there is all this additional complexity.

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

Not understanding what you mean by implicit vs. explicit.  I don't see
how what we've implemented is any more implicit than the current
specification.  If anything, I thought our impl was more explicit as
you can't derive the issuer from an opaque access token in the current
spec.


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

Internet applications trust Facebook, Google, whoever to identity and
authenticate users all the time and to grant access and permission
based on that identity.  An external exchange is just a non-browser
mechanism to facilitate this relationship.  For our IDP, our userbase
often use us as a broker between the various social websites and their
apps.  This way, apps don't care where the user was authenticated
from, they just see open id connect with a token format and domain
they control.  Developers often have apps that they are not able to
change how a user logs in or cannot unify their apps with a common
STS, token format, or even protocol.  Yet they still have a need to
make secure invocations across these domains and apps.

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

That's fair enough.  I didn't know how far in the process the token
exchange draft was.  In the least, I wanted to make the WG aware of
our work.  We have a decent and growing user base with a problem
looking for a solution and we're going to get a lot of feedback on
what we've implemented.   At least from our open source project
perspective, there's a lot more interest in external exchange than
internal.  Which is why I'm posting this.


-- 
Bill Burke
Red Hat