Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

David Waite <david@alkaline-solutions.com> Fri, 09 November 2018 18:44 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 2298E12D4EE for <oauth@ietfa.amsl.com>; Fri, 9 Nov 2018 10:44:26 -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, HTML_MESSAGE=0.001, 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 tucWttZ1sIuB for <oauth@ietfa.amsl.com>; Fri, 9 Nov 2018 10:44:24 -0800 (PST)
Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [173.255.196.46]) by ietfa.amsl.com (Postfix) with ESMTP id F3C20128CF3 for <oauth@ietf.org>; Fri, 9 Nov 2018 10:44:23 -0800 (PST)
Received: from [IPv6:2601:282:202:b210:31f6:1925:965a:44cc] (unknown [IPv6:2601:282:202:b210:31f6:1925:965a:44cc]) by alkaline-solutions.com (Postfix) with ESMTPSA id 18B5D31689; Fri, 9 Nov 2018 18:44:23 +0000 (UTC)
From: David Waite <david@alkaline-solutions.com>
Message-Id: <14BB75BB-F650-408D-8359-B25FA4E66DC9@alkaline-solutions.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A1FAE800-51DB-4D16-8BDF-8420562A3596"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Fri, 09 Nov 2018 11:44:22 -0700
In-Reply-To: <CA+iA6uinC=pp=0sQJyNUifd8HfRZk3-h+RXK4VnymVz2Rd++CQ@mail.gmail.com>
Cc: Aaron Parecki <aaron@parecki.com>, oauth <oauth@ietf.org>
To: Hans Zandbelt <hans.zandbelt@zmartzone.eu>
References: <VI1PR0801MB211299BED6B61582DC33B873FACB0@VI1PR0801MB2112.eurprd08.prod.outlook.com> <CA+iA6uinC=pp=0sQJyNUifd8HfRZk3-h+RXK4VnymVz2Rd++CQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/80cvXt2szXLg37E2kh7vefdFL1o>
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: Fri, 09 Nov 2018 18:44:26 -0000

Hi Hans, I hope it is acceptable to reply to your message on-list.

Others could correct me if I am wrong, but I believe the purpose of this document is to recommend uses of other OAuth/OIDC specifications, not to include its own technologies.

In terms of being another spec to be referenced, I think it would be useful but I wonder hypothetically how to best write that specification. This method seems to be relying on standards-defined tokens and converting them to an application server session, which isn’t defined by behavior other than HTTP cookies. The session info hook then lets you use those proprietary session tokens to retrieve the access/id token.

As such, it is closer to an architecture for implementing a client - as a confidential client backend with an associated SPA frontend that needs to make OAuth-protected calls. It is not describing the communication between existing OAuth roles, such as between the client and AS.

There’s obvious value here, and it's one of several architectures for browser-based apps using a confidential client rather than a public one (another example being a reverse proxy which maps remote OAuth endpoints into local, session-token-protected ones). I personally am just not sure how you would define the communication between back-end and front-end portions of the client in these architectures as a standard within OAuth.

-DW

> On Nov 6, 2018, at 3:03 AM, Hans Zandbelt <hans.zandbelt@zmartzone.eu> wrote:
> 
> Hi Aaron, DW,
> 
> About draft-parecki-oauth-browser-based-apps:
> would you consider including a recommendation about and the standardization of a "session info" endpoint (I'm open for better naming ;-)) as described in:
> https://hanszandbelt.wordpress.com/2017/02/24/openid-connect-for-single-page-applications/ <https://hanszandbelt.wordpress.com/2017/02/24/openid-connect-for-single-page-applications/>
> 
> this approach is not just something that I cooked up; it is based on real world requests & deployments at Netflix and OAth.
> 
> Let me know what you think,
> 
> Hans.
> 
> On Tue, Nov 6, 2018 at 10:55 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com <mailto:Hannes.Tschofenig@arm.com>> wrote:
> Hi all,
> 
> Today we were not able to talk about draft-parecki-oauth-browser-based-apps-00, which describes  "OAuth 2.0 for Browser-Based Apps".
> 
> Aaron put a few slides together, which can be found here:
> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-oauth-2-for-browser-based-apps-00.pdf <https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-oauth-2-for-browser-based-apps-00.pdf>
> 
> Your review of this new draft is highly appreciated.
> 
> Ciao
> Hannes
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> 
> -- 
> hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>
> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/>