I have been preaching this numerous time, but let me do it once more.
There seems to be a very common misperception that in OAuth that the Resource Owner (the entity who gives permission for the resource access, aka “authorization”) and the client user at the resource access time is the same. It is plainly wrong.
In OAuth, there are two distinctive phases.
- phase 1: Permission Phase
- phase 2: Resource Access Phase
Permission Phase gets the access token to the (OAuth) client, while in Resource Access Phase, the client uses the access token to access the resource.
In “phase 1: Permission Phase”, typically, the Resource Owner delivers access token to the client directly (e.g., implicit flow) or indirectly (e.g., code flow). The Resource Owner will be both at the authorization endpoint and the client’s redirection endpoint.
In “phase 2: Resource Access Phase”, the client accesses the protected resource using the access token. Many people seem to think that this client as “Alice” the resource owner. This is not correct. It could be anybody who controls the client. If and only if the client is used exclusively by Alice the resource owner, then we can safely assume that the user of the client is Alice. This is generally not true, especially when the client is a web service.
It is better to think of OAuth as Alice to Bob information sharing, where Bob is the controller/user of the client at the Resource Access Phase. There can be cases that Alice == Bob, but that is an exception.
Hi Nat, same problem occured in early days of the UMA spec. So we decided to call the Oauth Client (proxy) as the “Requester”. The human person operating the Client is called the “Requesting Party”. On the AS side, the human person setting the access policies on the AS is called “End-user”.