Probably one of you has heard the OAuth concept before. Essentially, OAuth is an authentication method that makes it possible for a 3rd party application to be authorized by the user to access user resources located on another service. OAuth is a compound word for O (Open) and Auth represents:
- Authentication: user authentication .
- Authorization: grants access to resources that users currently hold.
OAuth2 is an upgrade of OAuth1.0 , an authentication protocol that allows applications to share a part of resources with one another without the need to authenticate via username and password in the traditional way, thereby helping to reduce troubles. When we have to enter username, password in too many places or register too many password accounts that we can not remember at all.
Roles in OAuth2
In OAuth2 define 4 roles:
- Resource owner: is the user who is able to grant access, the owner of the resource that the application wants to retrieve.
- Resource server: a place to store resources, capable of handling requests for access to protected resources.
- Clients: are third-party applications that want to access shared resources as a resource owner and of course, before accessing the application, it needs to be authorized by the user .
- Authorization server: performs the task of authentication, checks the information that the user sends from that grants access to the application by generating access token snippets. Sometimes the authorization server is also the resource server .
Token
Token is a piece of code randomly generated by the Authorization server when a request is sent from the Client .
There are 2 types of tokens:
- Access token
- Refresh token
1.Access token
A piece of code used to authenticate access, allowing third-party applications to access user data to the extent that it allows. This token is sent by the Client as a parameter to be passed to the hreader during each request when accessing resources in the Resource server .
If an access token is lost, it can also be considered as revealing the password because it can take advantage of it to gain resources that it is protecting. Therefore, access token has a certain usage time (2 hours, 2 months …) depending on usage needs as well as security requirements. Access token is only used once, when it expires, the Client will have to send a request to the Authorization server to get a new access token .
2. Refresh token
Generated by the Authorization server , at the same time as the access token but different in function. The refresh token will be sent to retrieve a new access token when it expires, so it has a longer validity period than the access token . With access token the validity period may be 2 hours, the token refresh can be up to 10 hours.
The presence of refresh token makes it possible for the Client to regain access token without having to receive authentication from the user. If the user logs out, the token refresh will also be deleted.
Scope
Scope is a parameter defined in the Authorization server used to limit the rights and scope of resources that access tokens are allowed to access. The client determines which scope to use when requesting to generate an access token .
Classify
OAuth2 has 4 main types of identifiers:
- Authorization Code
- Resource Owner Password Credentials
- Implicit
- Client Credentials
Before going into details of each type of OAuth2, let’s explore through 2 terms used to identify clients with Authorization server:
- Client Identifier (Client ID): the character string used to identify the application.
- Client Secret: A string used to authenticate the Client when the application requires access to user account information. This string is kept secret between Client and Authorization Server.
Can understand the Client ID is the username , the Client Secret is the password of the Client for Authorization.
1.Authorization Code
This is the most common type used when the Client is a web server (Server-side Application). It allows you to retrieve a long-lived access token and can get a new access token via fresh token (if available).
For example:
- Resource Owner: Is you
- Resource Server: Google Server
- Client: Any website
- Authorization Server: Google Server
How it works:
- The user clicks the login button on the web application.
- The web application redirects the user to the Authorization server to begin receiving authorization code.
- The user is redirected to the login page.
- The user enters login information for authentication such as username and password .
- The authorization server will authenticate the login information and redirect the user to the application’s “uri redirect” (where the application captures information returned from the Authorization server) with a “authorization code” .
- The application (Client) sends the request to the Authorization server including the Client ID, the Client sercret (declared with the previous Authorization server) along with the code of authorization code just received.
- Authorization server will verify the information that the Client has just sent.
- If the information submitted by the Client is valid, Authorization will return the access token along with the refresh token (if any).
- The application sends a request to the Resource server with the received Access token.
- The resource server checks the access token, and if it is valid, returns it to the corresponding resource client that the access token allows access to.
2. Resource Owner Password Credentials
This allows third-party applications to retrieve tokens using information from a user’s account. This type is considered to be no more secure than Authorization Code , should only be used in some large websites or really trust because it directly processes user account information.
How it works:
- The user enters login information (eg username, password …) into the form on the application itself (Client).
- Application (Client) sends login information with Client ID, Client secret to the Authorization server.
- The authorization server checks the user’s login information as well as the identifier sent by the client, if all is valid then it returns the access token along with the refresh token (if any).
- The application uses the newly acquired access token to access the Resource server.
3. Implicit
This type is often used for mobile applications or applications that run on web browsers. In this type, access tokens are sent straight to the application via the URI in the browser. This method relies on the previously registered URI without passing any authentication method on the client side.
This type of authentication does not support token refresh .
How it works:
- User clicks on login on the web application side
- The user is redirected by the browser to the Authorization server.
- If the user allows access, the Authorization server redirects back to the application with an access token sent in the URI. For example:12https://example.com/oauth-callback#access_token=MNBD2DAasd99
- Now the application (Client) can query the Resource server through the newly obtained access token.
4. Client Credentials
This type of authorization serves the purpose of helping the Client authenticate itself with the Authorization server to access the resources it currently holds.
Like the above, Client Credentials does not support token refresh .
How it works:
- The client sends its own Client ID and Client secret to the Authorization server.
- Authorization server validates the information sent, if confirming it is a Client, then sends the access token again.
- The client uses that access token to access the Resource server to get resources.
Conclude
Above are the basic parts of OAuth2 that I can learn, hope they will be helpful to the boards.
The article is based on personal understanding so it is inevitable that shortcomings, people have questions or feedback, please comment down below so I can answer as well as supplement the article to be more complete.
Thank you for following the article.