Re: [OAUTH-WG] not using oauth for this architecture in oauth for browser based apps.
Justin Richer <jricher@mit.edu> Wed, 24 July 2019 14:19 UTC
Return-Path: <jricher@mit.edu>
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 6A54C120019 for <oauth@ietfa.amsl.com>; Wed, 24 Jul 2019 07:19:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 JLOYqSYzET_Y for <oauth@ietfa.amsl.com>; Wed, 24 Jul 2019 07:19:26 -0700 (PDT)
Received: from outgoing-exchange-5.mit.edu (outgoing-exchange-5.mit.edu [18.9.28.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8181F120020 for <oauth@ietf.org>; Wed, 24 Jul 2019 07:19:26 -0700 (PDT)
Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-5.mit.edu (8.14.7/8.12.4) with ESMTP id x6OEKiuV000982; Wed, 24 Jul 2019 10:20:47 -0400
Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 24 Jul 2019 10:18:17 -0400
Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by oc11expo18.exchange.mit.edu (18.9.4.49) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 24 Jul 2019 10:18:53 -0400
Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Wed, 24 Jul 2019 10:18:53 -0400
From: Justin Richer <jricher@mit.edu>
To: Leo Tohill <leotohill@gmail.com>
CC: Hans Zandbelt <hans.zandbelt@zmartzone.eu>, OAuth WG <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] not using oauth for this architecture in oauth for browser based apps.
Thread-Index: AQHVQDRSV6p1ICg+2UCIEh4jp0SA+qbXFs8AgAAMHACAALn/gIACOyyA
Date: Wed, 24 Jul 2019 14:18:53 +0000
Message-ID: <9D24AEB3-9858-4D78-99DE-C8F4FC9296AE@mit.edu>
References: <CABw+Fcuv2banmDtqC_6A4j6Vw7OgTLEDFOf0mn4YSeMaNkUsrA@mail.gmail.com> <67ed81f2-77dc-4acc-a499-2772c5fa4a85@getmailbird.com> <CA+iA6ujVp7C5QvzNHmRE3kV_VTgUQXWhTvJu5WaGt3nDKB8rzQ@mail.gmail.com> <CABw+FcuT+-+B57ZfyMmGXLjVYqDaq2p0_3juHd8H82MN24wpGw@mail.gmail.com>
In-Reply-To: <CABw+FcuT+-+B57ZfyMmGXLjVYqDaq2p0_3juHd8H82MN24wpGw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [31.133.148.255]
Content-Type: multipart/alternative; boundary="_000_9D24AEB398584D7899DEC8F4FC9296AEmitedu_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/9iNeL8qwuiBlWcEk60sYfrkZxYI>
Subject: Re: [OAUTH-WG] not using oauth for this architecture in oauth for browser based apps.
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, 24 Jul 2019 14:19:30 -0000
It would perhaps be better to phrase it as “don’t use OAuth in the JavaScript application directly” instead of “not entirely”. — Justin On Jul 23, 2019, at 12:14 AM, Leo Tohill <leotohill@gmail.com<mailto:leotohill@gmail.com>> wrote: I didn't see the earlier discussion (do you have a date or title?) so apologies if I'm bringing up something that's been resolved. But I still think that it's really confusing to say "it may be a better decision to avoid using OAuth entirely" if the application will still be using Oauth/OIDC (which will, of course, involve a browser flow). orsten@lodderstedt.net<mailto:torsten@lodderstedt.net> has raised the same (or similar?) objection in a parallel thread. I suggest we continue the conversation there. - Leo On Mon, Jul 22, 2019 at 1:09 PM Hans Zandbelt <hans.zandbelt@zmartzone.eu<mailto:hans.zandbelt@zmartzone.eu>> wrote: +1, as discussed before Hans. On Mon, Jul 22, 2019, 18:25 Brock Allen <brockallen@gmail.com<mailto:brockallen@gmail.com>> wrote: I think the implication is that the server-side would use something like OIDC to the token server in order to establish the identity of the user. The difference is that this would be driven from the server-side piece of the application, as any other normal server-side client would. The result would then simply be a cookie-based authentication session in the client, and any JS code would leverage the http only, same-site cookie for Ajax calls. -Brock On 7/21/2019 10:22:38 PM, Leo Tohill <leotohill@gmail.com<mailto:leotohill@gmail..com>> wrote: The advice for the architectural pattern "JavaScript served from a common domain as the resource server" reads: "For simple system architectures, such as when the JavaScript application is served from a domain that can share cookies with the domain of the API (resource server), it may be a better decision to avoid using OAuth entirely, and instead use session authentication to communicate directly with the API." I can agree that session authentication could be best here, but how was the user authenticated in order to create the trusted session? Wouldn't that/shouldn't that still use an oauth flow to collect credentials? We need to be clear on the distinction between browser based apps that hold the token(s) in the browser space, vs. those that don't. I agree that with this "common domain" architecture, the tokens should not be held in the browser, but it doesn't follow that oauth should not be used at all. Leo _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
- [OAUTH-WG] not using oauth for this architecture … Leo Tohill
- Re: [OAUTH-WG] not using oauth for this architect… Brock Allen
- Re: [OAUTH-WG] not using oauth for this architect… Hans Zandbelt
- Re: [OAUTH-WG] not using oauth for this architect… Leo Tohill
- Re: [OAUTH-WG] not using oauth for this architect… Justin Richer
- Re: [OAUTH-WG] not using oauth for this architect… Aaron Parecki