CODEWITHSUNDEEP
securityasp.net-web-apioauth-2.0authorizationidentity
user1620696
user1620696

Reputation: 11415

Is OAuth 2.0 just for authorizing applications and not users?

When I first heard of OAuth was in ASP.NET Web API applications and I've used it as means of authorizing users to access resources on a RESTful API. By the time I felt I was using it right, but right now I think I got the idea wrong and this is the subject of this question.

At the time, I used OAuth in the following way: on the API there was a token endpoint to issue tokens. I created a login page in a SPA and posted the username and password to the token endpoint with a grant type password and the token that came back I started sending with each request.

When the request had the Authorization: Bearer [token] header with a token issued with some username on the login page I understood the request was being done "with the user logged in" and so I could authorize access to resources.

Studying OAuth deeper my conclusion is that my usage of OAuth was completely mistaken.

My understanding now is that OAuth is just for authorizing applications and not users. In that case when we make a request with the Authorization: Bearer [token] header we are saying identifiying to the resource server that the client making the request has been authorized to access the resource, but we are not saying anything about the user?

In that case, with OAuth we just can say what resources client applications can access but we have no information to decide whether the user is allowed or not to the resource? Because of that my initial usage is truly wrong right?

Upvotes: 2

Views: 362

Answers (1)

MvdD
MvdD

Reputation: 23494

OAuth 2.0 can be used for authorizing a client (an application) to call an API. This authorization is done via an authorization grant.

The grant is given by the resource owner in the case of authorization code, implicit and resource owner password grant through authentication of the user with the authorization server and clicking accept on a consent screen.

The first two grant flows are interactive and require an agent that understands HTTP (redirection) responses.

Most authorization servers also support the client credentials grant. In this case, there's no user involved and a pre-registered client (application) uses its own client-id and secret to authenticate with the authorization server.

Which grant flow to use depends on the type of client you use and who owns the resource the client needs to access. I describe the differences in my answer here.

Upvotes: 1

Related Questions