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

Torsten Lodderstedt <torsten@lodderstedt.net> Fri, 12 August 2011 14:55 UTC

Return-Path: <torsten@lodderstedt.net>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id DC8E821F889F for <oauth@ietfa.amsl.com>; Fri, 12 Aug 2011 07:55:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id cqwbdBezMEAx for <oauth@ietfa.amsl.com>; Fri, 12 Aug 2011 07:55:51 -0700 (PDT)
Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de []) by ietfa.amsl.com (Postfix) with ESMTP id 517A421F8745 for <oauth@ietf.org>; Fri, 12 Aug 2011 07:55:50 -0700 (PDT)
Received: from [] (helo=webmail.df.eu) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1Qrt9u-0002Rn-FT; Fri, 12 Aug 2011 16:56:26 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Fri, 12 Aug 2011 16:56:26 +0200
From: Torsten Lodderstedt <torsten@lodderstedt.net>
To: oauth@ietf.org
Message-ID: <b7df18688b7612cb85418ed587b80044@lodderstedt-online.de>
X-Sender: torsten@lodderstedt.net
User-Agent: Roundcube Webmail/0.5.2
X-Df-Sender: torsten@lodderstedt-online.de
Subject: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 12 Aug 2011 14:55:52 -0000

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 


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 
server will be vulnerable to this threat, if it uses non-interactive
authentication mechanisms or split the authorization flow across 

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 
force a user interaction based on non-predictable input values as part 
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 
any approval by appropriate means, e.g. text message or e-Mail.