May 04, 2020

#SpringSecurity:Oauth 2.0 Roles

OAuth 2 is an authorization method to provide access to protected resources over the HTTP protocol.

It enables a third-party application to obtain limited access to an HTTP service:
a). Either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service
b). Or by allowing the third-party application to obtain access on its own behalf.

ALSO READ: What’s the difference OAuth 1.0 and OAuth 2.0?

OAuth 2.0 defines four roles: Resource Owner, Client, Resource Server and Authorization Server.
  • Resource Owner (User): The resource owner is the user, who authorizes an application to access his/her account. The application’s access to the user’s account is limited to the 'scope' of the authorization granted (e.g. read or write access).
  • Client (Application): It is the application (user is using) which require access to user data on the resource server. Before it may do so, it must be authorized by the user, and the authorization must be validated by the API.
  • Resource Server: It store user’s data and http services which can return user data to authenticated clients. The resource server hosts the protected user accounts, and the authorization server verifies the identity of the user then issues access tokens to the application.
  • Authorization Server: It is responsible for authenticating user’s identity and gives an authorization token. This token is accepted by resource server and validate your identity.
One of the good design decisions in OAuth 2.0 was to explicitly separate the roles of the authorization server from the API server. Because of this we have have a standalone component as authorization server, this component will obtain authorization from users and issue tokens to the clients.

ALSO READ: What is the difference between access and refresh token?

In Oauth 2.0 the authorization server and API server can be on physically separate servers, and even be on different domain names. This allows each part of the system to be scaled independently

Abstract Protocol Flow
1). The application requests authorization to access service resources from the user.
2). The user can either accept or deny the request. If the user authorized the request, the application receives an authorization grant else it will receive an error.
3). The application will send request to authentication server (API) to get the access token by presenting authentication of its own identity, and the authorization grant.
4). Once the identity of application is authenticated and validity of the authorization grand is checked, the authorization server (API) issues an access token to the application. This will complete the authorization flow.
5). The application can now requests the resource from the resource server (API) and presents the access token for authentication.
6). If the access token is valid, the resource server (API) serves the resource to the application.

-K Himaanshu Shuklaa..

No comments:

Post a Comment