Re: [OAUTH-WG] [EXTERNAL] Re: OAuth Redirection Attacks

Phillip Hunt <> Sat, 18 December 2021 16:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6EB723A1048 for <>; Sat, 18 Dec 2021 08:57:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5fwsZaFytMrz for <>; Sat, 18 Dec 2021 08:57:22 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::102a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 49B233A104A for <>; Sat, 18 Dec 2021 08:57:19 -0800 (PST)
Received: by with SMTP id rj2-20020a17090b3e8200b001b1944bad25so237695pjb.5 for <>; Sat, 18 Dec 2021 08:57:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=xaNdShmb4Ji6VlgMaH7LXFO0HzPeXAn6LbzCoTh+3xQ=; b=yKdb1ht0ZJSuMc2Gq86lJjwNxAIIcMuZlkkpwtk4igzVM6WRJr6jJGdfN9HrWCYdFn elYe3YLTEqD1sYBUfwju3RDZQsr75OsGDs/kTFhUQOZkxQU3bcFl4YUu4kQ9IWZA7OnQ ofS2JzVwwnbjwncODfajaTdhE9Vouc/i8WX4Kuqn1PfGx/egzOwwHWEmcEFF5YGt6ijj Kd863lQhsm4cizOkPL2NRwQiev7jbRcTqoT0/4bzev+xXmCvXXR/nIAQ0zdN9nzbl0+d HKVsY1UaOqbTyc60pnuZVlCl0pWwm/YDAkIj1IlqMNHKBn3s8r8K1BHwKE9TedkVd4qU nfWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=xaNdShmb4Ji6VlgMaH7LXFO0HzPeXAn6LbzCoTh+3xQ=; b=X4HiQsebRJ6Zq2nGaJWHm2wu4iWPmrJNJAnE0/gknEeNqsse2iSMorLJHjCf/XbA3M zffiaUFN3PG2KFlw8wXkNOi/1NCuLkPnbzwYkPnz0yl8h6DQJR4e/pWm179MylsaSNgm fPuca1D854AhbniqbmDJR/SR8H95kelFNzvYlusriUVNFFG80mqII/crN4zhTlsQEV8Y UkDQwp2CEpKyYof7mQhJhdqoqQAgbt45KP2hPRNX/V6U2UjL71NvmxQO+XAuXCdTr68j osazm83f3BzQL0SZj24rhSqwpwRUdqo7MLGXKu2z9mwddXJCCGPuRqYF4fNUv0rc4M+Y IIMg==
X-Gm-Message-State: AOAM531+YEyYmg5WIfk6w90xq5I8TZQG5P6ZyxjtFuQ4xfYKSeqWYj0e 75YMfMv0a1qN2WRwn37N5f1p6Q==
X-Google-Smtp-Source: ABdhPJzYxMrZQR2QQj8q7/vG5aDbj3RVuApc4JtwwPDnTXIVtvvi+ju4Dkr1aXKZg+PMQfpeE5oYBQ==
X-Received: by 2002:a17:90b:4d0e:: with SMTP id mw14mr18733973pjb.151.1639846637950; Sat, 18 Dec 2021 08:57:17 -0800 (PST)
Received: from ( [2001:569:7316:ae00:9165:f3be:a7:a0d9]) by with ESMTPSA id j1sm13953908pfu.47.2021. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 18 Dec 2021 08:57:17 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Phillip Hunt <>
Mime-Version: 1.0 (1.0)
Date: Sat, 18 Dec 2021 08:57:16 -0800
Message-Id: <>
References: <>
Cc: David Waite <>, Brian Campbell <>, oauth <>
In-Reply-To: <>
To: George Fletcher <>
X-Mailer: iPhone Mail (19B74)
Archived-At: <>
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: OAuth Redirection Attacks
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: Sat, 18 Dec 2021 16:57:27 -0000

Agreed. Most of dyn reg cases we were thinking about occurred because there was a need to register each copy of the same client software. The software statement was intended to allow the registration endpoint recognize software and to fix things like endpoints. 

Automatic registration of singletons is definitely suspect.  Do we need best practices?


> On Dec 18, 2021, at 7:11 AM, George Fletcher <> wrote:
> Given the attack is based on a successfully registered callback URL that is malicious, we can also look to the Authorization Server to run more checks on the registered callback URLs (e.g. check against the "unsafe" URL list). Not a 100% solution by any means but could help with reduce the impact. Additionally, making sure the AS can easily revoke any client_id and have that take effect quickly.
> Another potential option would be to not allow prompt=none (or automatic redirects) from contexts where the user hasn't first gone through a full authentication flow or at least allow the AS to display UI at it's discretion. Though this will definitely break some flows :(
> This at least illuminates one of the dangers of allowing a wide open dynamic client registration model :)
> Thanks,
> George
>> On 12/18/21 1:11 AM, David Waite wrote:
>>>> On Dec 17, 2021, at 2:44 PM, Brian Campbell <> wrote:
>>> Relax how aggressively OAuth demands that the AS automatically redirect in error conditions. And either respond with a 400 directly (which just stops things at that point) or provide a meaningful interstitial page to the user before redirecting them (which at least helps users see something is amiss). I do think OAuth is a bit overzealous in automatically returning the user's browser context to the client in error conditions. There are some situations (like prompt=none) that rely on the behavior but in most cases it isn't necessary or helpful and can be problematic.
>> The problem is that if prompt=none still requires redirection without prompt or interstitial, someone wishing to treat dynamic registrations of malicious sites as clients will just start using prompt=none. Likewise, a site could still attempt to manipulate the user to release information by imitating an extension to the authentication process, such as an "expired password change" prompt.
>> I agree with Nov Matake's comment - phishing link email filters should treat all OAuth URLs as suspect, as OAuth has several security-recommended features like state and PKCE which do not work as expected/reliably with email. Filters integrated into the browser (such as based on the unsafe site list in Chrome) should not need changes, as they will warn on redirect to the known malicious site.
>> We should also continue to push as an industry for authentication technologies like WebAuthn (as well as mutual TLS and Kerberos) which are phishing resistant. We are really talking about failure of a single phishing mitigation for _known_ malicious sites - the opportunity to use any unknown malicious site or a compromised legitimate site remains open even if we do suggest changes to error behavior.
>> -DW
>> _______________________________________________
>> OAuth mailing list
> _______________________________________________
> OAuth mailing list