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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
