Re: [OAUTH-WG] BCP: Client collaborative attacks

Neil Madden <> Tue, 27 October 2020 06:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 254B03A15BD for <>; Mon, 26 Oct 2020 23:26:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hxBH-vBq9_xz for <>; Mon, 26 Oct 2020 23:26:48 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CE0423A109F for <>; Mon, 26 Oct 2020 23:26:47 -0700 (PDT)
Received: by with SMTP id w23so226033wmi.4 for <>; Mon, 26 Oct 2020 23:26:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:mime-version:subject:date:message-id:references:cc:in-reply-to :to:content-transfer-encoding; bh=uG25yHc4PpXPdSqMiWKG8q02qNBNjyo34suXnN1cCsk=; b=HKggniGQiS41bDb1aBlKEHDah7srXIJcuHHXdDb0R9Yn5HvZZ8oM//QpE9PA3KhhxV JlekFud4bkYgX0UYMq0xBgVvV5ayKM30iWYxygRay1I6bmD4AXg+kIfbShm+x2pRyni1 DuIfbJyxaJ14DHk3Oe+C25pWLayCQHQpM9+k0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to:content-transfer-encoding; bh=uG25yHc4PpXPdSqMiWKG8q02qNBNjyo34suXnN1cCsk=; b=qkMzKwJQ4hEW5M0u77kgJX4M4Rlufd2mhdYQF1dXD/bhnOFkbouTjEYTYgUNQV44vq JRaxGm0C5EDUxots1ys/lPYHqxYVKLTU/LCjIGnihIJnJe36r8/Cmd7gq+77VfbaNiuV +Q13SpkVgPeJktTqOypxQKwYslaKn6XkY84FyTkHWFxCay7gUXHa42OHjiMorNseugyD QGMSGifTf8AdRymkcf+G+WB7zdK7dEz9lEWR4ADjYIUyxHUXVjMuTqY+GmzSqdlF8Zp2 IedHYLfqJDHXRuf3pxHksX8HGk8mzyesuq7oEfJZcMuWDlOcnGpTwgE00vx0CmdbbeHI ONNQ==
X-Gm-Message-State: AOAM532cCpoG4Lf+UfXrigWUXkvkbCqgIiSxfmLIdjYIX7DgTo7TMwQ7 oJhucw2ISmE5CAg4plb/vo22H9fspY3HXyvSdVWGSBnD7+/s8oEw/3solViDMQkBLrF6SBU6YA= =
X-Google-Smtp-Source: ABdhPJzrJ2mYkLrByon0kSu2IaahMlU3ZL6H0abSM/zzu1oHm4bARHwGis4WJI0p6jF5Uwwd0PyIPA==
X-Received: by 2002:a1c:6143:: with SMTP id v64mr850618wmb.108.1603780005453; Mon, 26 Oct 2020 23:26:45 -0700 (PDT)
Received: from ?IPv6:2a02:c7d:7263:bd00:99a9:fd2a:f83d:9a2a? ([2a02:c7d:7263:bd00:99a9:fd2a:f83d:9a2a]) by with ESMTPSA id y10sm646231wrq.73.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2020 23:26:44 -0700 (PDT)
From: Neil Madden <>
Mime-Version: 1.0 (1.0)
Date: Tue, 27 Oct 2020 06:26:44 +0000
Message-Id: <>
References: <>
Cc: Seán Kelleher <>, Denis <>, oauth <>
In-Reply-To: <>
To: "Manger, James" <>
X-Mailer: iPhone Mail (17H35)
Content-Type: multipart/alternative; boundary="Apple-Mail-BA500AA4-4CAF-4634-B7AD-A1F4336AAFFD"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [OAUTH-WG] BCP: Client collaborative 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: Tue, 27 Oct 2020 06:26:51 -0000

It sounds like we’re trying to redefine cooperation/delegation as an “attack”. People delegate and you can’t generally prevent it without incarceration. Anything Bob could do with Alice’s access token he could also do by asking Alice to do it on his behalf. In other words, any credential/token sharing can be replaced by proxying: If Alice wants to help underage Bob buy liquor she doesn’t have to share her access token, she can just buy it herself and give it to him. 

If the RS cares about accountability then the token (or some other means) should identify the user - perhaps pseudonymously like OIDC pairwise identifiers - and this should be logged for audit. But this can only discourage, not prevent, delegation. OAuth is after all a delegation protocol. 

(In the post-shame world we now live in, the idea that you can enforce norms through identification seems almost quaint, but I’m not sure I’m ready to be that cynical).

If the RS allows anonymous requests then there is obviously no accountability. Does that need to be explicitly mentioned?

— Neil

> On 27 Oct 2020, at 01:04, Manger, James <> wrote:
> It is worth mentioning “client collaborative attacks” or “authorization sharing attacks” because OAuth can make them easier (by packaging authority into an access token), compared to the alternative of user’s signing-in to an RS directly. But it is tricky to describe; none of the suggestions are quite right; and the “right” solution heavily depends on the context.
> >> If access tokens are used to identify individuals, and such identifying information (ideally user IDs) is stored with access logs for auditing purposes, then this reduces this attack to an authentication sharing attack.
> While this text from Seán may be true, it is bad advice. It implies we should make access tokens as dangerous as possible (conveying all a person’s authority) just to discourage sharing.
> > Since OAuth 2.0 does not mandate the use of cryptographic devices, this kind of attack cannot be countered in the general case.
> Even crypto devices aren’t a full solution. Alice can share her authorization with Bob & Chris by signing-in with their crypto devices.
> > an access token … only stating that the holder … is over 21 … should not be accepted by the RS
> While this may generally be true for an “over 21” claim, it will not always be true for other claims. In some situations the privacy risk of being personally identified is far more important than any risk of client collaboration. Staff accessing a company’s whistle-blower service could be an example: need a {staff:true} claim to combat spam/gossip; but definitely don’t want to include a staff id.
> A handful of partial strategies appropriate in various circumstances (but all with downsides) could include:
> 1. The AS ensures there is only 1 valid access token (or just a few) at any point in time for a specific claim of a given user.
> 2. Access token bound to a crypto key locked to one device.
> 3. Each access token is unique (eg includes a "jti" claim) so an RS can notice if the same token is presented in different contexts.
> 4. Access token with "sub" (or provides "sub" via token introspection) to aid accountability (even if only in a later audit/investigation).
> 5. Frequent token replacement.
> 6. Nothing (beyond minimal necessary claims) – to maximize privacy.
> What is applicable widely enough to mention in a BCP?
> --
> James Manger
> _______________________________________________
> OAuth mailing list

ForgeRock values your Privacy <>