Re: [OAUTH-WG] Feedback on OAuth for browser-based Apps

n-sakimura <> Sun, 28 July 2019 21:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8B44B120094 for <>; Sun, 28 Jul 2019 14:31:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id a0rJ71FiewiP for <>; Sun, 28 Jul 2019 14:31:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6C84C120048 for <>; Sun, 28 Jul 2019 14:31:23 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id F0CF4472EE6; Mon, 29 Jul 2019 06:31:22 +0900 (JST)
Received: from (unknown []) by (Postfix) with ESMTP id AFF134E0046; Mon, 29 Jul 2019 06:31:22 +0900 (JST)
Received: from (localhost.localdomain []) by pps.mf051 ( with SMTP id x6SLVMjp006368; Mon, 29 Jul 2019 06:31:22 +0900
Received: from ([]) by with ESMTP id x6SLVMqO006366; Mon, 29 Jul 2019 06:31:22 +0900
Received: from (localhost.localdomain []) by (Switch-3.3.4/Switch-3.3.4) with ESMTP id x6SLVOIj040497; Mon, 29 Jul 2019 06:31:24 +0900
Received: (from mailnull@localhost) by (Switch-3.3.4/Switch-3.3.0/Submit) id x6SLVOkL040496; Mon, 29 Jul 2019 06:31:24 +0900
X-Authentication-Warning: mailnull set sender to using -f
Received: from ([]) by (Switch-3.3.4/Switch-3.3.4) with ESMTP id x6SLVOsZ040493; Mon, 29 Jul 2019 06:31:24 +0900
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 29 Jul 2019 06:31:21 +0900
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 29 Jul 2019 06:31:20 +0900
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=eIq8hJNVT9/whWqKoPN+DLAHgPkVkCr7zBIr4KOAd/WxakY6YKGNDZQqvHTdKsWK8c17PztXj/2Ug3WmFldT9pN013eFVnyDdycm4yadT0a8l1+C7kP2VPXeR+At1x+B4mwEAmmdI5Mx/iG6htOBPzf/tFa4Q8p0EWB1Jk9ICAvHIZ+hpqrN1eTZCvOXBktJ7Dk166A3RhSE9shC9P8m/n90LRSZ8Viwh6v9gOOeSuypxO6YUN3uYB9dckSfTpSOTpESCWjdw1Y0b+3Nytw8ZvkIrJLuAulUowpuwg/cOcmpSe47W+XmsPcmzQmRdfX8iYchHaYlScQbXDBqzV5Y2g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mydvS3+UWD30w4IrJKfgJiId75BuUCrBnvgvLw9DNrY=; b=Ckg6o1a453sM+m8A9BWK/gaIPWysea6eDLk5Fy8S1mDZkJ/bKAZVFhHYFJ8CwxkwHwWa87IhhnGKkN8kqjvKcGDq3uKEP+5fVZdfRk/fIipYsIaesAajPGHZYlItayyy/yB/U64NBbXqx5MB+Mu4/rxoA6Bd5o58VyShLdgyzUpXab/iP1/O8ZMa3UHEfruT72vF50bFAl7o7iZyuLBcICN1NY7vIMSqTs0cXeQ77hRIwtpJaqK6+d834F6f924CPZSzzBwzSBYZzcrJqIJbeXtboZCfQFtufMZwfea04XXx0gEdZI3JQ3f+UiNdImbAUgIKNazpMTYQ0eJNLgtBmA==
ARC-Authentication-Results: i=1; 1;spf=pass;dmarc=pass action=none;dkim=pass;arc=none
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.15; Sun, 28 Jul 2019 21:31:19 +0000
Received: from ([fe80::a506:c36d:83ec:1b33]) by ([fe80::a506:c36d:83ec:1b33%6]) with mapi id 15.20.2115.005; Sun, 28 Jul 2019 21:31:19 +0000
From: n-sakimura <>
To: Justin Richer <>, David Waite <>
CC: OAuth WG <>
Thread-Topic: [OAUTH-WG] Feedback on OAuth for browser-based Apps
Date: Sun, 28 Jul 2019 21:31:19 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
x-mailadviser: Ver 3.40R03
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8d9273ad-eadf-4a5c-1d93-08d713a2ee2b
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:TYAPR01MB2255;
x-ms-traffictypediagnostic: TYAPR01MB2255:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01128BA907
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(376002)(39830400003)(396003)(136003)(199004)(189003)(51444003)(606006)(26005)(6506007)(53546011)(8936002)(256004)(14444005)(66066001)(186003)(71200400001)(71190400001)(478600001)(2906002)(476003)(3846002)(486006)(446003)(76176011)(68736007)(86362001)(102836004)(81166006)(81156014)(966005)(14454004)(8676002)(99286004)(6116002)(7736002)(7696005)(11346002)(46636005)(66574012)(25786009)(9686003)(236005)(53936002)(76116006)(66556008)(66476007)(66446008)(66946007)(64756008)(6436002)(6246003)(55016002)(110136005)(2171002)(74316002)(52536014)(5660300002)(229853002)(6306002)(316002)(4326008)(54896002)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:TYAPR01MB2255;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: e10L7R0NsHUmkhqp4cT5TfVhvPWfsHOWlg/nVQjQiVP/H6vDWSU1f8CMW9QdfgEJ191Ux6xXoiOvb4He5y4lbCWOZjnD+IeJKU7gDdB1yrdUuuTWBf0ajMyiVMr+ZO2cx6bCXKT0UYA5gc2FhoqveuJktUGQrTgLMkszvysYofGBq1+36E5HwfDrXiteL609/SNiKmtHk9LjOzfxb22usAqaqFGto3XqB/nTH1NLpUNSisvhywe9QfWRDysCFtJR9GPVYk4gqzaX6220fVK8+BoKd3VadjFuywTqbjq+hPmA27nNJof7ww20243vSCh4Wt/LUZBF03ReDt+ws6LUdKvJZVXRiDvngHzW8uyqQw308waI38fHlVlUuj4pskVqc8F8YaAlerhVPpdaBhIAXHe6jS7l8BvHvhZliSXZ8SQ=
Content-Type: multipart/alternative; boundary="_000_TYAPR01MB44137F45D4A889A933612885F9C20TYAPR01MB4413jpnp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 8d9273ad-eadf-4a5c-1d93-08d713a2ee2b
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2019 21:31:19.6797 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: e3e360d9-7e7f-48d5-ac33-3c5de61f0a75
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR01MB2255
Archived-At: <>
Subject: Re: [OAUTH-WG] Feedback on OAuth for browser-based Apps
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: Sun, 28 Jul 2019 21:31:29 -0000


On the related issue, issue of exporting the access token that a confidential client got to a public client is there as it was discussed in the Friday’s Oauth WG meeting. Though I did not make any comment on Friday as we were running out of time, I think that is a bad idea as the AuthZ server has issued it assuming that it is kept by a confidential client.

Hybrid response type was made because of the view that the public client should get less privilege.

If we are getting rid of Implicit flow, this aspect need to be addressed.

Having said that: if SPA is using the code flow, is it not acting as a public client without a client secret?


From: OAuth [] On Behalf Of Justin Richer
Sent: Thursday, July 25, 2019 8:45 PM
To: David Waite <>
Cc: OAuth WG <>
Subject: Re: [OAUTH-WG] Feedback on OAuth for browser-based Apps

This raises an interesting question that I don’t think we’ve addressed yet: how to appropriately vary token lifetimes and access for different clients.

Previously, an AS could see that a client was using the implicit flow and decide to limit token lifetimes or scopes based on that alone. Similarly, I know of at least some AS implementations that let you limit what scopes you allow under the client credentials grant. The key issue is that if all your clients are using the auth code flow (which I agree they should), then how does an AS tell the difference in capabilities between incoming clients?

Obviously it can do it on a per-client basis still, but now an AS is going to have to know a bit more about the app itself. Perhaps we finally need a few more entries in the “application_type” metadata parameter from OIDC’s extension RFC7591 beyond “native” and “web”? But we at least probably want to point out to AS implementors that this is something they want to consider tracking in their data model for clients.

— Justin

On Jul 25, 2019, at 4:04 AM, David Waite <<>> wrote:

On Jul 24, 2019, at 3:03 PM, Aaron Parecki <<>> wrote:

On Mon, Jul 22, 2019 at 2:14 AM Dominick Baier
<<>> wrote:

I would rather say that ANY JS app should use CSP to lock down the browser features to a minimal attack surface. In addition, if refresh or access tokens are involved - further settings like disabling inline scripting (unsafe inline) and eval should be disabled.

I'm not sure what to do with this suggestion. It feels like a blanket
recommendation of enabling CSP will likely be ignored since it's too
broad, and recommending disabling inline scripts is overreaching
unless backed up by a specific threat it's protecting against. Did you
have a particular threat in mind?

I would say that browser applications should take measures to harden their applications again code injection and arbitrary code execution. Examples include eliminating inline script (and limiting embeddable objects as much as possible) via CSP, and versioning third party resources via techniques like subresource integrity.  Mechanisms such as augmenting the codebase to make sure all appropriate user input, data storage, and output properly sanitize data may be used - although they may be more expensive to implement and audit.

The AS should likewise take into account an application’s overall security posture when deciding appropriate policies around delegated authorization scopes and token lifetimes.

Best current practices include turning the screws tightly around CSP. But it is (theoretically) possible to accomplish the same with brute-force sanitization, which has been made simpler with framework support. It is still ultimately the AS job to decide which clients have which capabilities.

OAuth mailing list<>