Re: [OAUTH-WG] Additional WGLC review of OAuth 2.0 Security Best Current Practice by an AAD developer
Benjamin Kaduk <kaduk@mit.edu> Thu, 28 November 2019 02:48 UTC
Return-Path: <kaduk@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 B0696120B0D for <oauth@ietfa.amsl.com>; Wed, 27 Nov 2019 18:48:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 kmMyt66IW6yv for <oauth@ietfa.amsl.com>; Wed, 27 Nov 2019 18:48:39 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 6887912097F for <oauth@ietf.org>; Wed, 27 Nov 2019 18:48:39 -0800 (PST)
Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xAS2mXZL007974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 27 Nov 2019 21:48:36 -0500
Date: Wed, 27 Nov 2019 18:48:33 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Message-ID: <20191128024833.GP32847@mit.edu>
References: <DM6PR00MB0572EE0273CC912EC73BEA05F5470@DM6PR00MB0572.namprd00.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <DM6PR00MB0572EE0273CC912EC73BEA05F5470@DM6PR00MB0572.namprd00.prod.outlook.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/83y3awIaSZKZ7vZQWhBvOw4kwDk>
Subject: Re: [OAUTH-WG] Additional WGLC review of OAuth 2.0 Security Best Current Practice by an AAD developer
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: Thu, 28 Nov 2019 02:48:41 -0000
On Thu, Nov 28, 2019 at 12:12:54AM +0000, Mike Jones wrote: > Please also add these WGLC comments that a Microsoft Azure Active Directory (AAD) developer asked me to convey: > > > 1. In 4.12, "Authorization servers MUST determine based on their risk assessment whether to issue refresh tokens to a certain client [...]" I'm not sure what this requirement requires in practice. AAD issues refresh_tokens to all clients upon request and user consent and applies different lifetime policies to different clients. We also routinely make risk assessments about all manner of things. Does AAD thereby comply with this guideline? Reading the whole paragraph, I think the paragraph is trying to encourage OAuth clients which use a RT when the RT is returned but use auth codes when the RT is not returned. That's fine, but the current text comes off as imposing a vague requirement on authorization servers. Edits inline - "Authorization servers MUST MAY dynamically determine based on their risk assessment whether to issue refresh tokens to a certain client. If the authorization server decides not to issue refresh tokens, the client may SHOULD refresh access tokens by utilizing other grant types, such as the authorization code grant type. In such a case, the authorization server may utilize cookies and persistent grants to optimize the user experience." FYI... Using HTML bold/strikethrough doesn't work very well in the text/plain portion, which is the only one displayed in the official archives: https://mailarchive.ietf.org/arch/msg/oauth/Yzw0Mk4Ke3yyCH0Oo7MmatXA_tg -Ben
- [OAUTH-WG] Additional WGLC review of OAuth 2.0 Se… Mike Jones
- Re: [OAUTH-WG] Additional WGLC review of OAuth 2.… Benjamin Kaduk