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

Brian Campbell <bcampbell@pingidentity.com> Mon, 11 December 2017 23:24 UTC

Return-Path: <bcampbell@pingidentity.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 B802412711D for <oauth@ietfa.amsl.com>; Mon, 11 Dec 2017 15:24:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 WajeQvnAuHvK for <oauth@ietfa.amsl.com>; Mon, 11 Dec 2017 15:24:01 -0800 (PST)
Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 17AE2124239 for <oauth@ietf.org>; Mon, 11 Dec 2017 15:24:01 -0800 (PST)
Received: by mail-it0-x22f.google.com with SMTP id d16so19947567itj.1 for <oauth@ietf.org>; Mon, 11 Dec 2017 15:24:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HgsjySPNz2hB0ZYwkPh/tWvoRzrDZq8FwozXqRgzQ/0=; b=RJtOoicaEwBNT1pTc5IuiZLO/td4X0oskVNZxnXe7Q3+gPSvmFa+FTEDLy3G+NhTiP 3LfaXEaNNZhratAQ2QqQ5qgaWeEkTMruerrzgiqNuM/kJb2NqSf8vndYYmz30wNvPsCt YvIojALjJIF7Jcu1EQUUag+2XEfAfJKs9/VKw=
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=HgsjySPNz2hB0ZYwkPh/tWvoRzrDZq8FwozXqRgzQ/0=; b=dNiD/RbW24bNLvBcBmhvw/FfH/TGbYtUQwsRbAhFJ6z6BDrCrtBhNbICLDzYmmQ6AK UwzZFC7fVQEexyNWHYnCjWSY/v3qnpodXEoAu8bwxcWfafoN9IU4mEchPxl5s7DAkDcg UHi9os8xlFO8EM8VHYrhL50u3aTXFNI26YgnrdnUNSdMdfncRcI5XvJHCHDwhGp63GG6 pPC2chNY3BcVBhxs6yXAqDNQ94c7tT8Wwpp+3DPitS1YgZThi88DoXLr8Pgx9JcOdEt2 3QtddsQj2Ui+84gFEuViLoxjSPRaeU7PRvz36cwPntqw+kmMStN8gCSenCt7G2RgqfGU ma5Q==
X-Gm-Message-State: AKGB3mKU1vNWdU08+0Gc3+k5HVjFYCpV69R64MJv3crLWZ/VeoONNdF2 MFgKo9/eyu3NGzwTyvlNDO9ZlMmUD9TSqICA/dGEwYh8SAJ/sIdJ4de5TIXMTmjlOsFQ1vxBpIp Ftzu1TZhfcaDfIEDa
X-Google-Smtp-Source: ACJfBou87gNmmuIPC4hGMzdvmzk/W31Xmj1bODznXkYc8X8c3HtrS74KOdeUl2CjFgVNjfEQvl64JID6SAGO2Keh9vE=
X-Received: by 10.36.95.14 with SMTP id r14mr8605itb.42.1513034640050; Mon, 11 Dec 2017 15:24:00 -0800 (PST)
MIME-Version: 1.0
Received: by 10.2.118.194 with HTTP; Mon, 11 Dec 2017 15:23:29 -0800 (PST)
In-Reply-To: <CABRXCmzy48wR3Q5MrGnsbZh6AQbAW_5Lrd8zstqBnk+Q1XMEsA@mail.gmail.com>
References: <CABRXCmwBV+OxxihkK31sDzBZbaTDP3XFvpdL=_ekreO1N_gy_g@mail.gmail.com> <CA+k3eCS0YexwKEBVLXRkqdwpfgcr8aseTtmFe=D=BXF_JofXLA@mail.gmail.com> <CABRXCmzy48wR3Q5MrGnsbZh6AQbAW_5Lrd8zstqBnk+Q1XMEsA@mail.gmail.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Mon, 11 Dec 2017 16:23:29 -0700
Message-ID: <CA+k3eCSUqj-fT7jN_1eggbqZ=uRF3QX3Z6hLw+Q5XfXaJU=Z6A@mail.gmail.com>
To: Bill Burke <bburke@redhat.com>
Cc: OAuth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="001a1144b57a40ef3d056018d462"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Jy-ZjYgK7brV1muEb-W2_i2gANQ>
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: Mon, 11 Dec 2017 23:24:04 -0000

The words implicit vs. explicit might not have been the best choice but the
concepts are complicated and subtle and I was (and still am) at a bit of a
lose for the right language to describe things.

By explicit what I was trying to express is that the token that is going
cross-domain is explicitly intended for that purpose and includes things
like an audience restriction that reflect that intention. The OpenID
Connect ID Token is an example of that for browser based flows and the RFC
7523 JWT authorization grant is an example for non-browser flows.

By implicit what I was trying to express are situations where a token that
issued for a particular purpose (like a Facebook access token for access to
Facebook APIs) is used implicitly for a different purpose (like getting a
different access token for access to APIs in a different domain).



On Fri, Dec 8, 2017 at 2:29 PM, Bill Burke <bburke@redhat.com> wrote:

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

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