Re: [OAUTH-WG] not using oauth for this architecture in oauth for browser based apps.
Aaron Parecki <aaron@parecki.com> Wed, 24 July 2019 21:44 UTC
Return-Path: <aaron@parecki.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 B4F1D120159 for <oauth@ietfa.amsl.com>; Wed, 24 Jul 2019 14:44:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.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 7yHxhD-YvLX0 for <oauth@ietfa.amsl.com>; Wed, 24 Jul 2019 14:44:07 -0700 (PDT)
Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 E82B01202EC for <oauth@ietf.org>; Wed, 24 Jul 2019 14:44:06 -0700 (PDT)
Received: by mail-io1-xd31.google.com with SMTP id k8so92877716iot.1 for <oauth@ietf.org>; Wed, 24 Jul 2019 14:44:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Bb96RIuM/BB+bJJKPD9Ik4BjkppOoYwTNwI8T0gnbxw=; b=j17g7TCDhIhfsre3TjEwgo6PlHnki2gYaZV5qIOVOd0m12GkBHHLM7dIFo1aFAKghr Y4s11d8zVteaqblsxURGpg8qh7Oq6f/SPuppF8wQrBNt0xXFBfcK9YIpVdoOBC9hSNGo WoTcNX5ME3BR34CjEv98pyr6F1UOY8wldvPT9Sgs56BNYwO7r3eidzl+OSZOERWnFYJl DY9l9Gz81EYUjzwv1ic1MbXrUKKlhGKNLX9G2dsDlmTmkwVGA3V2LVjb/bnwk/GQDa0N 6uaYbfepGAvdPnfgrGtkmLi1Lbkuf8SLSRbnXoE8Akoz0xW8oJHst1XYmNLQmzRDlhJU yodQ==
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=Bb96RIuM/BB+bJJKPD9Ik4BjkppOoYwTNwI8T0gnbxw=; b=nfRtJht3IvP55Bw6mxa30PPzK4R5w3ggWX993gMfM3XeCC/Eo9TcoE/uAA0/5vCTr3 yJfN21al9l7B9EjbAcFIqXdTXB7lC7kJ1EOBTVLM8lmWgvjCf9H4lMBAoajEH+lZMM0y kejQskN2yt4CfKDITa1XtZtvgMpnSN9BAgJaVq2hfsNAtSBphdqzZNMbTN8cXYJaIfuA bVJAdrID31cYbRRFKEu3hgjDC4yDbZDiy0Z56kljrpORDPKOldjgacSwp4/EYY7NJizZ 37riTLJL7mtmssW35qTxSXDye2U6D66O96visrncAUknIW71/+e1LBgiMqJgENigQufy j2TA==
X-Gm-Message-State: APjAAAUTYU+cM7PGMPCkWm5dA8un9nxtK8cmNQuT/LkB1rWVfKe3CSVt z4I8pqWh9+kCV8JRTh7lg++Crar0gNj7/Q==
X-Google-Smtp-Source: APXvYqzvKb6v/tWCZ4wfQttUeVqQni7YczkrJOoKjp52tJCwX5LemgDohA92v2rGiO12UugqOz8/Kw==
X-Received: by 2002:a6b:b756:: with SMTP id h83mr47783657iof.147.1564004645932; Wed, 24 Jul 2019 14:44:05 -0700 (PDT)
Received: from mail-io1-f42.google.com (mail-io1-f42.google.com. [209.85.166.42]) by smtp.gmail.com with ESMTPSA id r24sm34405635ioc.76.2019.07.24.14.44.04 for <oauth@ietf.org> (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jul 2019 14:44:05 -0700 (PDT)
Received: by mail-io1-f42.google.com with SMTP id e20so62423895iob.9 for <oauth@ietf.org>; Wed, 24 Jul 2019 14:44:04 -0700 (PDT)
X-Received: by 2002:a5d:80c3:: with SMTP id h3mr70818467ior.167.1564004644761; Wed, 24 Jul 2019 14:44:04 -0700 (PDT)
MIME-Version: 1.0
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> <9D24AEB3-9858-4D78-99DE-C8F4FC9296AE@mit.edu>
In-Reply-To: <9D24AEB3-9858-4D78-99DE-C8F4FC9296AE@mit.edu>
From: Aaron Parecki <aaron@parecki.com>
Date: Wed, 24 Jul 2019 17:43:00 -0400
X-Gmail-Original-Message-ID: <CAGBSGjrZKanquG9SKZ5AoVcPYd93+4g+e-5E3FOQHGCB324ZuQ@mail.gmail.com>
Message-ID: <CAGBSGjrZKanquG9SKZ5AoVcPYd93+4g+e-5E3FOQHGCB324ZuQ@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: Leo Tohill <leotohill@gmail.com>, OAuth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000047368d058e7435f1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/6ypEA5KOR6j5GcKw3K-Z-wLNEA8>
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 21:44:10 -0000
There are two primary aspects of OAuth that are undesirable in this situation: 1) Using a redirect-based OAuth flow to obtain an access token adds unnecessary attack vectors to the application (see all the redirect-based attacks in the Security BCP) 2) Storing the access token somewhere accessible to JavaScript is unnecessary since the JS doesn't need access to it if it can share a cookie domain with the API (RS) These are the main points I am trying to get across in this section, so I've expanded that section to mention these points more explicitly. I've rephrased the whole section, added a reference to potentially using the "SPA with backend" option in the following section, but there is still the lingering case of: If your JavaScript application has no backend, but still shares a domain > with the resource server, then it may be best to avoid using OAuth entirely. Is it worth pursuing this to try to find an OAuth-based solution for this particular architecture? (The app, AS and RS share a common domain, and there is no backend other than the RS.) Something like a cookie-based OAuth flow? ---- Aaron Parecki aaronparecki.com @aaronpk ---- Aaron Parecki aaronparecki.com @aaronpk <http://twitter.com/aaronpk> On Wed, Jul 24, 2019 at 10:19 AM Justin Richer <jricher@mit.edu> wrote: > 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> 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 <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> > wrote: > >> +1, as discussed before >> >> Hans. >> >> On Mon, Jul 22, 2019, 18:25 Brock Allen <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 >>> <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 https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > 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