Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
David Waite <david@alkaline-solutions.com> Thu, 22 November 2018 04:21 UTC
Return-Path: <david@alkaline-solutions.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 0E42612D4ED for <oauth@ietfa.amsl.com>; Wed, 21 Nov 2018 20:21:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 T7qyln8NuACl for <oauth@ietfa.amsl.com>; Wed, 21 Nov 2018 20:21:56 -0800 (PST)
Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [173.255.196.46]) by ietfa.amsl.com (Postfix) with ESMTP id 79D95124BE5 for <oauth@ietf.org>; Wed, 21 Nov 2018 20:21:56 -0800 (PST)
Received: from [IPv6:2601:282:202:b210:d540:185e:d973:299a] (unknown [IPv6:2601:282:202:b210:d540:185e:d973:299a]) by alkaline-solutions.com (Postfix) with ESMTPSA id D69EF315E9; Thu, 22 Nov 2018 04:21:54 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: David Waite <david@alkaline-solutions.com>
In-Reply-To: <CA+iA6ughRVoYyX4ZPb11NO8YLZpwkeVaCToZGxnX213x8M-x4Q@mail.gmail.com>
Date: Wed, 21 Nov 2018 21:21:53 -0700
Cc: George Fletcher <gffletch@aol.com>, "oauth@ietf.org" <oauth@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C117F42E-6D2E-42F8-B65F-4CC8AFE829CC@alkaline-solutions.com>
References: <VI1PR0801MB211299BED6B61582DC33B873FACB0@VI1PR0801MB2112.eurprd08.prod.outlook.com> <CA+iA6uinC=pp=0sQJyNUifd8HfRZk3-h+RXK4VnymVz2Rd++CQ@mail.gmail.com> <14BB75BB-F650-408D-8359-B25FA4E66DC9@alkaline-solutions.com> <1b451ff4-9de5-c3e2-acf3-f8b50b0212ff@aol.com> <CA+iA6ughRVoYyX4ZPb11NO8YLZpwkeVaCToZGxnX213x8M-x4Q@mail.gmail.com>
To: Hans Zandbelt <hans.zandbelt@zmartzone.eu>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/vic1RVOn8GiIb0BS8jV_BiffKww>
Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 22 Nov 2018 04:21:58 -0000
> On Nov 21, 2018, at 12:08 AM, Hans Zandbelt <hans.zandbelt@zmartzone.eu> wrote: > > I think of this as somewhat similar to: > a) a grant type where a cookie grant is exchanged at an "RP token endpoint" for an associated access and refresh token; the protocol between SPA and the API to do so would benefit from standardization e.g. into SDKs and server side frameworks > b) an "RP token introspection endpoint" where the cookie is introspected at the RP and associated tokens are returned > > if anyone comes up with a better name for this model and endpoint (and probably less overloading of AS endpoint names...) and/or is willing to help writing this down, please come forward and we'll pick it up on a new thread/doc Hand waving follows :-) This sounds like the RP environment as two pieces, a javascript application and back-end infrastructure. The RP infrastructure maintains local tokens which it derives from remote tokens issued by a single upstream AS/IdP, which it interacts with as a confidential client. This RP infrastructure separately manages authentication/authorization for a javascript application. In this use case, this infrastructure allows the javascript application to get the access token issued by the upstream AS, so that the javascript application may then act as the client to interact with protected resources associated with that AS. (For protected resources within the RP environment, a separate local token is used for authorization; possibly a non-OAuth token such as the cookie) The first requirement of access token exposure sounds like a fit for token exchange, with the RP exposing its own authorization service token endpoint for this purpose, and the javascript acting as a public client to the RP and not to the upstream OAuth AS. The “cookie token” would have a specific token type for this use case. Multiple exchanges would potentially return the same upstream access token, or could silently use the refresh token if needed to acquire and return a fresh access token. In this scenario I would not expose the refresh token, as the javascript application should not have a direct relationship with the upstream AS, nor should it have credentials to perform the refresh. Likewise, the id_token was addressed to the RP infrastructure and not the javascript application - I would expect authentication interactions to be between the RP infrastructure and the javascript application, indirectly based on the RP infrastructure’s relationship upstream service. Once the javascript app has the access token, it should be able to use it to interact with a user info endpoint. This might be a RP user info endpoint, or the upstream user info endpoint, depending on RP requirements. FWIW, if there are multiple upstream AS’s, I would expect the local RP environment to be a ‘full fledged’ AS issuing its own local access tokens, and to provide its own local protected resources which then may dispatch to the protected resources of the various upstream AS’s as needed. Everything above could be reused in this scenario, although you might just decide to have the local protected resources accept the cookie directly in addition to the local RP environment access tokens. -DW
- [OAUTH-WG] draft-parecki-oauth-browser-based-apps… Hannes Tschofenig
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Aaron Parecki
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Joseph Heenan
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Simon Moffatt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… David Waite
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Tomek Stojecki
- [OAUTH-WG] draft-parecki-oauth-browser-based-apps… Daniel Fett
- [OAUTH-WG] draft-parecki-oauth-browser-based-apps… Daniel Fett
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… David Waite
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… David Waite
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Brock Allen
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Brock Allen
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Brock Allen
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Brock Allen
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Daniel Fett
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… n-sakimura
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Tomek Stojecki
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Brock Allen
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Brock Allen
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Brian Campbell
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Vladimir Dzhuvinov
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Vladimir Dzhuvinov
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Hans Zandbelt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Jim Manico
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Aaron Parecki
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… George Fletcher
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Hans Zandbelt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… David Waite
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Brian Campbell
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Hannes Tschofenig
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… John Bradley
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Rob Otto
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Aaron Parecki
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Phil Hunt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… David Waite
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Hans Zandbelt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… David Waite
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… John Bradley
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Aaron Parecki
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Brian Campbell
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Aaron Parecki
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Vittorio Bertocci
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Aaron Parecki