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

Hans Zandbelt <hans.zandbelt@zmartzone.eu> Wed, 21 November 2018 07:08 UTC

Return-Path: <hans.zandbelt@zmartzone.eu>
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 923AB130EDF for <oauth@ietfa.amsl.com>; Tue, 20 Nov 2018 23:08:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=zmartzone-eu.20150623.gappssmtp.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 apLNdD50TlX5 for <oauth@ietfa.amsl.com>; Tue, 20 Nov 2018 23:08:21 -0800 (PST)
Received: from mail-it1-x133.google.com (mail-it1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 4C57C127332 for <oauth@ietf.org>; Tue, 20 Nov 2018 23:08:21 -0800 (PST)
Received: by mail-it1-x133.google.com with SMTP id b5so7466597iti.2 for <oauth@ietf.org>; Tue, 20 Nov 2018 23:08:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zmartzone-eu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7euNjT196GOL7XNDg4/hS4ovspmPG+dJn0GkfX/fic8=; b=FoTahU0ZmhdUkAEbLuGP5I7y+kXG16tsaIPp0+podRYuU9v3XQOz+KVNUbTthG42lC ilAEkJhQoE/aQB6lVzc7dCkxPkkz4QpLLlTuudXJvAstcB0SptRbnTcNJhHgf59kh6sS dDdcIIwuqh9JfJ0EG9sk0qt03ovKSSUQJLB/eEKLn1CIEwhLtdpLFXBYQW+TWZHDxU27 7j93pTIVnLSzMXqqTp08d3i8hkY0ageTJ9spup9PR0kRwUTPi2B0q1Xi+PBUEm6gnPqv dfEz/+v2ByGc9Eg3kH32vGYXkvHuVjrZZeIyp2buNBwkMk3LyS12u60dHiFrClJvwiCL 05zQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7euNjT196GOL7XNDg4/hS4ovspmPG+dJn0GkfX/fic8=; b=Raat5H6s5wI6MvfMT37NiDpqKak6WUXe+KEmKmfgRh/o5S8xrlkhngaxh34Y48EWqi HZJJBQ3h54PAz7Oj/feHKjZ1Zc5ZoMYkttb0AHnHjbK3pia7KUoSeZxt8M3OczPEmLhu zs57sT98sj4YcF/67QHYLUomeNep/jH/md3qeBheoMcKiVbE1Z1o9xNq7aqkM4O+snYK e1e2bSZWnYW7dyPedvc6SKm7aKLl8L+rK2Wj9zNluCVojalg/J9hyc5zcdRDmRMyODn4 ZMVevnqdPz9GF5+2sTFEIvjjiMUpuahB+/BFAhuhv78TRzIY15RPcbwtn4g+Bs1G/ZM9 qHrA==
X-Gm-Message-State: AA+aEWba0OOJ0jBEiz7pf5wbr+C6Z4aP/05tA4kAhi6qbktWrwGvo+sI I0YPBucIEEvhdgMr8graqo/2AnRuP2aInym7xCQlqg==
X-Google-Smtp-Source: AJdET5fmLH8LC9HYXOEL2PiI60M73sKDU1randnBuSaMz+VpIDemdigHjjJe/5Nf9SSPWJwghzSfLlBw+dAraIUKreU=
X-Received: by 2002:a02:89dd:: with SMTP id e29mr4689505jak.21.1542784100504; Tue, 20 Nov 2018 23:08:20 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <1b451ff4-9de5-c3e2-acf3-f8b50b0212ff@aol.com>
From: Hans Zandbelt <hans.zandbelt@zmartzone.eu>
Date: Wed, 21 Nov 2018 08:08:08 +0100
Message-ID: <CA+iA6ughRVoYyX4ZPb11NO8YLZpwkeVaCToZGxnX213x8M-x4Q@mail.gmail.com>
To: George Fletcher <gffletch@aol.com>
Cc: David Waite <david@alkaline-solutions.com>, "oauth@ietf.org" <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000046b31b057b276a1b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/9bsrp0TJzYZ4WwPQQE6F7fC3WTw>
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: Wed, 21 Nov 2018 07:08:25 -0000

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

Hans.

On Tue, Nov 20, 2018 at 11:00 PM George Fletcher <gffletch@aol.com> wrote:

> +1
>
> This model is useful and should be documented in its own right. Once
> documented it could possibly be referenced in the BCP.
>
> On 11/9/18 1:44 PM, David Waite wrote:
>
> 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/
>
> 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> 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
>>
>> 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
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
> --
> hans.zandbelt@zmartzone.eu
> ZmartZone IAM - www.zmartzone.eu
>
>
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
>

-- 
hans.zandbelt@zmartzone.eu
ZmartZone IAM - www.zmartzone.eu