Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02

Leo Tohill <> Tue, 09 July 2019 00:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 67A7B120090 for <>; Mon, 8 Jul 2019 17:44:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.702
X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UUi2GWoA8HbX for <>; Mon, 8 Jul 2019 17:44:43 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8053312023F for <>; Mon, 8 Jul 2019 17:44:43 -0700 (PDT)
Received: by with SMTP id az7so1673336plb.5 for <>; Mon, 08 Jul 2019 17:44:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8p/OkHqesq7qStWDom5uUp4ie3iV/3kCzVNO6jvYYYs=; b=pKzoElta7t6/ugXpt2xz6OemtDvz/funFYOguBpWym4SppdtOchVkbtfr+7h0VFHxj 6CqWTf2PqdOKzBD7LBOfAHpXzS2vbGC3FKL0VjL2DqbbLbJ3E9Z50CYGn1grzM1MzeRy 4/Q6oKg5BCVaY/KKxiaWXHAsUHDGobSWiVYPXaVALfDjuY39ZfNXOBHBa+X4tX+BndJ3 ZYA3W5L5JSZHo1k59cFe9XlPmQ102W73BIK1tCPL3gVZ5zD9PV/BGl1m6Bsa3KzGcZ28 byVxamjx0ypF7m/wfbEjLKFjpQNwaBEVm1hNMErwnZVnWdB3Wme07rcwZ2OXEtfgKbbX GQxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8p/OkHqesq7qStWDom5uUp4ie3iV/3kCzVNO6jvYYYs=; b=HCKYl9LwcFw/XXs63XCNVoRY0LUCDFQHaPf08HyH6J1gZjOVqklolugVhOW64gMNHb rx7E67Igqo72iNptuAzY6HBHzGtJxDsCCAPkTgrveu/lsYsxeHrKa44Z2sPCX9vapFGr UbNFPtXNK/NcODnO8eblhs2ry6iXRxznhQQHExsbm7SXVIcT6I3m1Mpq182s8/07LU+o 3rLXyQc+Y7YyoYlT4p8194UuNDbOY7HYZBW1CWk+tjjqzO9mDizZycM5PbKGMJFOExIa pQhySzxiqmdSuAXWQ8Lok9Y3D8+tahH44BddN3Pr0ni8Axmgbf/TPLcGD7JiSteQhaNS CFPw==
X-Gm-Message-State: APjAAAWCjqTOz+YFTwISvXx645Ionab4PErsDNkIXZe6EiG1VlIFvEir 9asNRJHRk34gn/FwgSNS7KgZDqGm+Rniq2tIc3LXqqMPOXM=
X-Google-Smtp-Source: APXvYqxOK72dCg0+LvmrUSB+pocOTQQuVugc/aghaJXSp7i/wjpd4RwaFlAbj2nGWjXmGsGuyOZ43V/XrTqFMmjh8pI=
X-Received: by 2002:a17:902:4283:: with SMTP id h3mr27680227pld.15.1562633082779; Mon, 08 Jul 2019 17:44:42 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Leo Tohill <>
Date: Mon, 8 Jul 2019 20:44:31 -0400
Message-ID: <>
To: Aaron Parecki <>
Cc: OAuth WG <>
Content-Type: multipart/alternative; boundary="000000000000d03c32058d34dd45"
Archived-At: <>
Subject: Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Jul 2019 00:44:46 -0000

 regarding 6.1. Apps Served from a Common Domain as the Resource Server

Isn't this recommendation neglecting some benefits  or use cases of Oauth?

* An application that doesn't collect user credentials is an app that
doesn't need to be audited for problems such as password leakage into log
* Applications that offload authentication to a identity server can
delegate to that server the complexities of MFA, password recovery,and the
like.  Of course these CAN be done in the app, but isn't it sometimes
better to centralize those features in a identity server?  Especially if
the organization has multiple apps that require these features.

I would soften " it is likely a better decision"  to "it may be a better


On Mon, Jul 8, 2019 at 7:05 PM Aaron Parecki <> wrote:

> Hi all,
> I've just uploaded a new version of oauth-browser-based-apps in
> preparation for the meeting in Montreal.
> This draft incorporates much of the feedback I've received over the last
> couple months, as well as what we discussed at the last meeting in Prague.
> The primary change is a significant rewrite and addition of Section 6 to
> highlight the two common deployment patterns, a SPA with and without a
> dynamic backend.
> Please have a look and let me know what you think. I have a slot in the
> agenda for Montreal to present on this as well.
> Thanks!
> ----
> Aaron Parecki
> _______________________________________________
> OAuth mailing list