I am now studying about the topic, and as far as I understand OAuth 2.0 is supposed to be a protocol for users authorization in a web server. When it comes to authentication its pretty straight forward - the client sends a request to the identity provider, receives a token that contains additional information (JWT for example), he then sends that token to the app server, the app server validates the token with the identity provider. All good until here.
My problem is authorization - knowing which permissions that user possesses in the app server. As far as I understand, the "scope" part of the request refers to things that the user allows the app server to do on his entity in the identity provider, so it is authorization but it authorizes only the app server.
Does the protocol contains any way for the app server to authorize the client, or it assumes that data like the roles and scopes of each user would be managed by the app server? I guess such data could be sent by the identity provider on the token, but then how are the permissions of each user managed with the identity provider? Is it part of the protocol? If not, why is it called "authorization protocol"?
How does OAuth2.0 implements authorization?
Viewed 45
2 Answers
The purpose of OAuth2 is to allow the client application to call an API server on behalf of the user. The scopes define what the client application can do to the user's data on that API server. This is called delegated authorization as the user delegates some permissions to the client application.
Now some authorization servers allow you to define roles for a resource server and include these as claims in the access token. It's an implicit contract between the authorization server and resource server how these roles are interpreted. Roles are not part of the OAuth2 RFC.
Adding to what MvdD said, authorization means a user grants a client application some access to a protected resource that that user owns.
When the user is sent to the authorization server to authenticate, the authorization server is supposed to ask something along the lines of, "Do you allow this client application access to your protected resource?" Sometimes you'll see it as "X application wants to see your email, address, phone number, ..."
Scopes specify what actions are allowed. The access token that allows the client app access to the protected resource. The resource server should allow only the actions associated with the scopes in the access token.
Related