Skip to content

OAUTH2 Components#

OAUTH2 Components#

  • OAuth 2.0 has the following components:
Components Descriptions
The Resource Server Where the protected resources owned by user if present like photos, personal information, transactions etc/
The User (also known as resource owner) The person who owns resources exposed by the resource server. Usually the user will prove his identity with the help of username and password.
The Client The application that want to access the resources owned by the user on their behalf. The client uses a client id and secret to identify itself. But these not same as user credentials.
The Authorization Server The server that authorizes the client to access the user resources in the resource server. When the authorization server identifies that a client is authorized to access a resource on behalf of the user, it issues a token. The client application uses this token to prove to the resource server that it was authorized by the authorization server. The resource server allows the client to access the resource it requested if it has a valid token after validating the same with Auth server.

 #zoom

  • To understand easier, let's take a look on the example image above. Assume that we have a user who is the resource owner of some projects in his GitHub Resource Server. Then this user want to use a third party application which is the SonarCloud to analyze his projects for detecting bugs and vulnerabilities. In this scenario the SonarCloud is the Client application and It will ask the user to go to the GitHub Authorization Server to enter the credentials for proving his identity. Then if the identity is approved, the GitHub Authorization Server will issue a token to the user. So once the Client receives the token, this token will be send to the GitHub Resource Server to get the resources like his projects for scanning and analyzing. In this step, the GitHub Resource Server will validate the token issued by the GitHub Authorization Server is valid or not by connecting with the GitHub Authorization Server. It means everytime the Client send the token to the GitHub Resource Server so it will connect to GitHub Authorization Server to validate.

  • Moreover, based on these 4 components we have 5 different grants and flows for applying OAuth2 to generate a token from Auth Server. Each grant type is optimized for a particular use case, whether that's web app, a native app, a device without the ability to launch a web browser or server-to-server applications.

    • Authorization Code
    • Implicit
    • Resource Owner Password Credentials
    • Client Credentials
    • Refresh Token

See Also#

References#