Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)

Eran Hammer-Lahav <> Thu, 18 August 2011 05:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 66AD121F85EC for <>; Wed, 17 Aug 2011 22:58:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.557
X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0YCFCB9y8lK4 for <>; Wed, 17 Aug 2011 22:58:46 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id C513121F85E3 for <>; Wed, 17 Aug 2011 22:58:46 -0700 (PDT)
Received: (qmail 4268 invoked from network); 18 Aug 2011 05:59:39 -0000
Received: from unknown (HELO ( by with SMTP; 18 Aug 2011 05:59:39 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([]) with mapi; Wed, 17 Aug 2011 22:59:39 -0700
From: Eran Hammer-Lahav <>
To: Torsten Lodderstedt <>, "" <>
Date: Wed, 17 Aug 2011 22:58:23 -0700
Thread-Topic: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
Thread-Index: AcxZAD9oCYx+xdzVQuy705Z1zNxKpgEaydKw
Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345029DFA960@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 18 Aug 2011 05:58:47 -0000

I've read the thread leading to this, and the proposed text and I do not understand the attack. Can you provide a step-by-step scenario of how an attacker gains access?

Also, it is unlikely that any major provider is going to require CAPCHA as part of the authorization flow. This is especially true in the case of using OAuth for login which has to be practically transparent (one click). I would hate to recommend a solution that no one is going to take seriously.

I'm keeping this proposed text out until we resolve this questions.


> -----Original Message-----
> From: [] On Behalf
> Of Torsten Lodderstedt
> Sent: Friday, August 12, 2011 7:56 AM
> To:
> Subject: [OAUTH-WG] Draft 20 last call comment (Resource Owner
> Impersonation)
> Hi all,
> I think the impersonation issue as raised by Niv on the list should be covered
> by the core spec. It directly aims at the trustworthiness of the user consent,
> which in my opinion is one of the core principles of OAuth. I therefore
> suggest to add a description to section 10.
> Please find below the text Niv and I prepared. In comparison to  Niv's original
> proposal, it covers resource owner impersonation for all client categories.
> regards,
> Torsten.
> proposed text:
> 10.<to be determined> Resource Owner Impersonation
> When a client requests access to protected resources, the authorization flow
> normally involves the resource owner's explicit response to the access
> request, either granting or denying access to the protected resources.
> A malicious client can exploit knowledge of the structure of this flow in order
> to gain authorization without the resource owner's consent, by transmitting
> the necessary requests programmatically, and simulating the flow against the
> authorization server. An suthorization server will be vulnerable to this threat,
> if it uses non-interactive authentication mechanisms or split the authorization
> flow across multiple pages.
> It is RECOMMENDED that the authorization server takes measures to ensure
> that the authorization flow cannot be simulated.
> Attacks performed by scripts running within a trusted user-agent can be
> detected by verifying the source of the request using HTTP referrer headers.
> In order to prevent such an attack, the authorization server may force a user
> interaction based on non-predictable input values as part of the user consent
> approval.
> The authorization server could combine password authentication and user
> consent in a single form, make use of CAPTCHAs or one-time secrets.
> Alternatively, the authorization server could notify the resource owner of
> any approval by appropriate means, e.g. text message or e-Mail.
> _______________________________________________
> OAuth mailing list