Re: [OAUTH-WG] We appear to still be litigating OAuth, oops

Jeff Craig <> Fri, 26 February 2021 21:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D89A53A0C6D for <>; Fri, 26 Feb 2021 13:59:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 daJN8H07cHbU for <>; Fri, 26 Feb 2021 13:59:21 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6296C3A0CE7 for <>; Fri, 26 Feb 2021 13:59:11 -0800 (PST)
Received: by with SMTP id k2so9319931ili.4 for <>; Fri, 26 Feb 2021 13:59:11 -0800 (PST)
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=0mo5kSM5uOXr0KRtpFXNSYSKx376YyXV/5Cp7AlExrA=; b=q9HYQ4ycrxZcyveBuCm3zTTwOTt2uPtej6Xb01sE4p7M0MiPQ8K0Uu7qsKE9o/3L0f 3lV8J9SJ6dx2zDthauHSMI1Za0EhUxhw/DMdkdpvnYiFVGrq4OUYSmlzM/Nk6GlADrX5 JAH1usrIfl+ivRiPBegEKbCyO2xIb90VHFrF2nlFNDXwcWXptoG9sCvX/WqJDwmceLAB Moyr/iw4pQq+Q+8yABP3wSzN2BH8KWikgUO9BDEoiSmi7UCsFGAlfVPrIocPHtX4wSYv 2unhavvuL+NslXqGGC+RjIQSelcPKINOKxtODSqLuYf/agx7kbXL90ccAwHlyNvpPhoa STQQ==
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=0mo5kSM5uOXr0KRtpFXNSYSKx376YyXV/5Cp7AlExrA=; b=awXRxc+sml34mIj/n/KGf1phoU3ombJ7uazO5MzE/EW7dIZaaEy5WugzX7lc+zibZg CSrX7uqfujBzV7qjgMPxzBex8QGu4k7h8ihsNUGeSYiTKhq/U5XeBmaEA+pRc9Dtx/Bd NhEqgTqJbM2R5/S2RBEGiAeuh8dbMgmW/CQ3aA7+Va1+qoS6LYEdOupa/OeheifLKpUF 6yit4D5EdGRl5sEbUpQ2SsPBt1D+GAv/sWmEcON/QKvr70jmgczbcUoDvk7xro8vn05H Y1LWAUWgOW8GwsBZyvClpdWrZArDjysseFhzqWSYsFOD1elAF6geuznw38xwKLkM75u0 5TRQ==
X-Gm-Message-State: AOAM531+023OzgoWAclRaQ4Zyj+9bkMuqnNkQ3hQVGrcDvF4Uv3cFWjR yXFeqFkfWUxDpozGVtYCzoMDXd8wesEfZ8xK3MOCkw==
X-Google-Smtp-Source: ABdhPJyN7yFOxvYdKLz1gj8sj86qjbl0ZTToCVb4nInqSRO3OOf1IzaTiuh7LrhiWz9o/qk4qDfQyDgNzf3YfNd+mmc=
X-Received: by 2002:a92:cb49:: with SMTP id f9mr4006813ilq.0.1614376750338; Fri, 26 Feb 2021 13:59:10 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Jeff Craig <>
Date: Fri, 26 Feb 2021 15:58:58 -0600
Message-ID: <>
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
To: Aaron Parecki <>
Cc: David Waite <>, Bron Gondwana <>, Phillip Hallam-Baker <>, "" <>, IETF-Discussion Discussion <>, Warren Parad <>
Content-Type: multipart/alternative; boundary="000000000000bd3aec05bc4460df"
Archived-At: <>
X-Mailman-Approved-At: Mon, 01 Mar 2021 07:09:56 -0800
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 Feb 2021 21:59:24 -0000

On Fri, Feb 26, 2021 at 3:50 PM Aaron Parecki <> wrote:

> > Do you disagree that this gives them control over which things talk to
> their servers?
> Yes -- with a public client, I can impersonate a "real" app and it's
> basically non-detectable by the AS. For a theoretical example, if I wanted
> to use the Instagram API but they restrict which apps can upload photos to
> only their own mobile apps, I can find the client ID of their own app, then
> do an OAuth flow using their own client ID, and without a client secret it
> looks the same as their own client. I'm unlikely to be able to get
> arbitrary users to authorize my app because of limits and checks on the
> redirect URI, but I can certainly do it myself for my own account. This is
> the sort of false sense of security provided by the client registration
> step I'm talking about.

The fact that you're unlikely to be able to get arbitrary users authorized
as the client is precisely the attack vector that registration is meant to
avoid. The fact that any reasonably sophisticated AS is going to use
additional signals (Referer headers, etc) to limit the scope of the Public
Client to make hijacking harder, which is only possible with registration,
is another line of defense. OAuth doesn't need to protect *your* data from
you, it needs to protect other people's data from you, and registration
offers more opportunities to collect signals that can be used to protect

None of it's perfect, and I agree that there are problems in the
app-identification space that need some additional work, but the
registration friction does serve a purpose in a lot of cases.

> I'd love to solve the app identity problem too, but that's only possible
> with cooperation from the mobile OSs.
> Aaron
> On Fri, Feb 26, 2021 at 1:36 PM David Waite <>
> wrote:
>> > On Feb 26, 2021, at 9:32 AM, Aaron Parecki <> wrote:
>> > The point is that basically nobody uses it because they don't want to
>> allow arbitrary client registration at their ASs. That's likely due to a
>> combination of pre-registration being the default model in OAuth for so
>> long (the Dynamic Client Registration draft was published several years
>> after OAuth 2.0), as well as how large corporations have decided to run
>> their ASs where they want to have (what feels like) more control over the
>> things talking to their servers.
>> Do you disagree that this gives them control over which things talk to
>> their servers?
>> FWIW my personal mental model here is pretty simple:
>> With users, there are services you provide anonymously and services you
>> provide only to registered/authenticated/trusted parties for various
>> reasons. Once you are delegating user access, you still have many of the
>> same reasons to provide access to anonymous or
>> registered/authenticated/trusted delegates.
>> Dynamic registration arriving later and requiring additional complexity
>> has unfortunately encouraged registration in use cases where anonymous
>> clients might have been acceptable, but shifting the timelines or
>> complexity balance would not  have changed business needs for
>> authentication and trust of delegates. Omitting registration would have
>> caused businesses to use other protocols that met their needs.
>> If AS’s are only getting what feels like proper control for their
>> business needs, we should attempt to give them the actual control they
>> require.
>> -DW
> _______________________________________________
> OAuth mailing list