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

[Torsten Lodderstedt <[e-mail]>]

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.