Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best Current Practice"
Daniel Roesler <daniel@utilityapi.com> Fri, 08 November 2019 12:50 UTC
Return-Path: <daniel@utilityapi.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 76E8A1200C5 for <oauth@ietfa.amsl.com>; Fri, 8 Nov 2019 04:50:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=utilityapi.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 wAqsoaIsc2Ol for <oauth@ietfa.amsl.com>; Fri, 8 Nov 2019 04:50:17 -0800 (PST)
Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (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 83B5F120086 for <oauth@ietf.org>; Fri, 8 Nov 2019 04:50:17 -0800 (PST)
Received: by mail-qv1-xf2b.google.com with SMTP id g12so2110498qvy.12 for <oauth@ietf.org>; Fri, 08 Nov 2019 04:50:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=utilityapi.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=nrmA2b5oip4kC0RuyZmSkw+7F/ozylD/sLqM2Gf0aVA=; b=sV2ROlOkO9ZZjf8aPm8b12I7YW7dHQhYICwLhdG30nwu56hBbOsYgNOvCYYQAJenwq W1Y6nq+S8aoO+dl0cXYTnEwvk+skRIdwX3Rpq4NRoLgqt1JeHEwbMBxaFuDTsAF9MSbB JQYnDA1ELfSGtJZ9yKgj5UUwpM1StCwRccO6Q=
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:content-transfer-encoding; bh=nrmA2b5oip4kC0RuyZmSkw+7F/ozylD/sLqM2Gf0aVA=; b=sAKLYRgp/dqwB9Ei7XlP/wQcsomArHpuCbJ0zJ2U2nnS4NhguodO1tWpcHM4ZwpCIb 8d6gZNK+DLsh3ZdXgWDi05lgyVAfft7jYtO1k/8KvYUTu9mPwcbfXZT/vYBWS9vt9kE9 /OYR7EieaRvgAUDQ4V/GogGXW5k7LM9/3K1PDfQ9kMD6OVxpkqEwHe3zAjuBf+fuoBSO 4fCOCfs/WMFbmsM9B61brTGefaNrW441bxVSY0XKIhDeTnJaLUzOynrjABwwUwb6lp7R 3/5If6c/UtuxiW8oOZ1nJpxSWsnbqTolFNjP++Z7lDcF4ahIrof847Uoy+MupDDNixG0 3AWQ==
X-Gm-Message-State: APjAAAXnkG+380tQvjDumUXukL8HDF83Gb08Y3uV1jdfC1siRuwcG269 RvhTLVH8XBDsmwX1jbCGqYi1n6vpsfy1jWIjrDMG+3n+VmQ=
X-Google-Smtp-Source: APXvYqxTWwMj7OvA3FARC0g90V4YFtRwW5kKA8QT6Xmmhb9rhLyRLT1fnz3DfnfB2ldQiyZd5sJpmVsPHR48vECe6ls=
X-Received: by 2002:a0c:b88f:: with SMTP id y15mr9287880qvf.161.1573217416166; Fri, 08 Nov 2019 04:50:16 -0800 (PST)
MIME-Version: 1.0
References: <VI1PR08MB5360FBBAF0D3A38BDBED618BFA790@VI1PR08MB5360.eurprd08.prod.outlook.com>
In-Reply-To: <VI1PR08MB5360FBBAF0D3A38BDBED618BFA790@VI1PR08MB5360.eurprd08.prod.outlook.com>
From: Daniel Roesler <daniel@utilityapi.com>
Date: Fri, 08 Nov 2019 06:49:40 -0600
Message-ID: <CAF2Zz1RPt4sfoNuPMLJOPJPUCVo1Go8VvJNJSuM88Eouc9KSMA@mail.gmail.com>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/YMznTv-14c47Q2s1vQ1Y2pu58A0>
Subject: Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best Current Practice"
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: Fri, 08 Nov 2019 12:50:20 -0000
Howdy, In the "3.1 Protecting Redirect-Based Flows" > "3.1.1. Authorization Code Grant" section, is there guidance on when it is appropriate (if ever) to automatically generate a new authorization code and redirect back to the client? A recent exploit[1] on Github's OAuth implementation was practical because if you make an authorization request and the resource owner is already authenticated and the scope is already authorized, Github will silently generate a new authorization code and redirect the user back to the redirect_uri without asking them to click "Authorize" again. How the exploit worked: 1. The client makes an ajax HEAD request to the OAuth authorization endpoint, which will silently create the authorization grant (this was the security exploit that was patched). 2. However, since the ajax response was blocked via CORS, the client couldn't receive the authorization code in the response parameters. 3. So, the client then redirected the user to Github's authorization endpoint with the same authorization code request (only this time as a real GET redirect). 4. Github instantly redirected the user back to the client's redirect_uri with a new authorization code and without asking for any user interaction. It seems strange to me that OAuth should allow for transparent authorization code redirects without resource owner confirmation. This situation only comes up when something weird is happening, such as when a client loses their valid access|refresh_token, but isn't that all the more reason to clarify that you should always ask for resource owner confirmation of the scope, even in scenarios where you are just re-authorizing the same scope as before? Had Github asked for confirmation on step 4 above, the practicality of the HEAD exploit would have been reduced because the user would have been presented with an unexpected Allow/Deny Github OAuth dialogue, possibly alerting them to the fact that something strange was going on. Anyway, I'm trying to find guidance on transparent redirects for authorization code grants. There's a whole host of both security and application logic issues that could come up from such behavior, so I'd like to ask for clarification in best practices. [1]: https://blog.teddykatz.com/2019/11/05/github-oauth-bypass.html Daniel Roesler Co-founder & CTO, UtilityAPI daniel@utilityapi.com On Wed, Nov 6, 2019 at 2:27 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote: > > Hi all, > > this is a working group last call for "OAuth 2.0 Security Best Current Practice". > > Here is the document: > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13 > > Please send you comments to the OAuth mailing list by Nov. 27, 2019. > (We use a three week WGLC because of the IETF meeting.) > > Ciao > Hannes & Rifaat > > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
- [OAUTH-WG] WGLC for "OAuth 2.0 Security Best Curr… Hannes Tschofenig
- Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best … Jared Jennings
- Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best … Justin Richer
- Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best … Denis
- Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best … Daniel Fett
- Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best … Denis
- Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best … Hans Zandbelt
- Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best … Daniel Roesler
- Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best … Denis
- Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best … Hans Zandbelt
- Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best … Daniel Fett
- Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best … David Waite
- Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best … Daniel Roesler
- Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best … Torsten Lodderstedt
- Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best … David Waite
- Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best … Lee McGovern
- Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best … David Waite
- Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best … Denis
- Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best … Vineet Banga
- Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best … Torsten Lodderstedt
- Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best … Vineet Banga
- Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best … Torsten Lodderstedt
- Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best … Vineet Banga
- Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best … Torsten Lodderstedt
- Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best … n-sakimura