OAuth2: Things we should not ignore.

This story begins in the year 2020, when we were Nestjs writing Restful APIs using the Nestjs framework. After about a year when the project went into production, my clients have new requirements. However, at that time I was a fan of Golang and suddenly realized I had to solve one more problem. That is the problem related to Authentication and Authorize . While I was still struggling with where to go, I was fortunate to be told by the masters and started to learn the OAuth2 protocol from there. Today, I will share with you what I have learned from OAuth2 . Let’s get started !!!

What is OAuth2?

• OAuth2 is version 2 of the OAuth protocol. This protocol allows third-party applications to grant limited access to an HTTP service on behalf of the resource owner, or to allow access by third-party applications on its own behalf. Access is required by a guest, be it a website or mobile app .
• Version 2 is expected to simplify the previous version and make interaction between different applications easier.
• The specification is still being compiled and the protocol is still evolving, but that doesn’t stop it from being installed and welcomed by giants like Google or Facebook .

Basic knowledge:

Role (OAuth2 defines 4 roles):

• resource owner : This is usually you.
• resource server : a server that stores protected data (eg, Google stores data about your profile and personal information).
• client : the application requests access to a resource server (be it your PHP website, Javascript application, or a mobile application).
• authorization server : the server that generates the access token for the client. This token is used by the client to send a request to the resource server. This server could be similar to the authentication server (which would normally be).

Token (Authentication Code): Authentication code is a random string generated by the authentication server and released when requested by the client.

1. There are two types of authentication codes :

• Access token : This is the most important code because it allows third-party applications to access user data. This code is sent from the client as a parameter or as a header in the request sent to the resource server. It is limited to the time in effect by the authentication server. it needs to be secured as soon as possible but we’ll see that that’s not always possible, especially when the client is a web browser making a request to the resource server using Javascript.
• Refresh token : This is issued with the access authentication code, but unlike the access authentication code, it is not sent in each client request to the resource server. It is only sent to the authentication server to renew the access token when it has expired. For security reasons, it is not always possible to obtain this code.

2. Scope of access authentication code :

• Scope (scope) is a parameter used to limit the rights of access authentication code. The authentication server is where the scopes are defined. The client needs to submit usage scopes to his application while sending the request to the authentication server. The narrower the range, the more likely the owner of the resource to grant access permission.

3. HTTPS :

• OAuth2 requires the use of HTTPS when communicating between the client and the authentication server because sensitive information is exchanged between these two components (authentication codes or possibly resource owner credentials ). You don’t really have to do this if you build your own authentication server, but you should be aware that you are making a major security hole by doing so.

4. Register as a client :

• When you want to retrieve data from the resource server using OAuth2 , you must register as the authentication server client. Each supplier is free to allow this according to the method of their choice. The protocol specifies only the parameters that must be specified by the client and those to be returned by the authenticating server. Here are the parameters (they can vary depending on the carrier):

• Authentication server response:

Authorization grant types:

OAuth2 identifies four types of authorization, depending on the location and nature of the client involved in obtaining the access authentication code.

1. Authorization Code Grant :

When should it be used ?

• It should be used as soon as the client is the web server. It allows you to get a persistent access token as it can be renewed with a refresh token (if the authentication server allows it).

For example :

• Resource owner: you.
• Resource server: a Google server.
• Client: any website.
• Authentication server: a Google server.

Situation :

• A website wants to get information about your Google profile. You are redirected by the guest (website) to the authentication server (Google). If you allow access, the authentication server sends the authorization code to the client (website) in the callback response. This code is then exchanged (exchange) with the access authentication code between the client and the authentication server. The website can now use this access token to query the resource server (Google) and retrieve your profile data. You never see the access authorization code, which will be hosted by the website (eg during session). Google also sends other information along with the access authentication code, such as token lifetime and finally a refresh token. This is an ideal and safer situation because the access authentication code is not passed through the client side (the web browser in the example).

Sequence diagram

2. Implicit grant :

When should it be used ?

• It is typically used when the client is running in a browser that uses scripting languages ​​like Javascript. This type of authorization does not allow the issuance of a refresh token .

For example :

• Resource owner: you.
• Resource server: a Facebook server.
• Client: a website that uses AngularJS for example.
• Proxy server: a Facebook server.

Situation :

• A client (AngularJS) wants to get information about your Facebook profile.
• You are redirected by the browser to the authentication server (Facebook).
• If you allow access, the authentication server redirects you to the web page with the access authentication code in the (fragment) URI segment (not sent to the web server). Callback example: http://example.com/oauthcallback#access_token=MzJmNDc3M2VjMmQzN .
• This access token can now be accessed by the client (AngularJS) and used to query the resource server (Facebook). Example of the query: https://graph.facebook.com/me?access_token=MzJmNDc3M2VjMmQzN .

Có thể bạn tự hỏi làm cách nào mà ứng dụng khách có thể thực hiện lời gọi đến API Facebook bằng Javascript mà không bị chặn vì chính sách nguồn gốc giống nhau (Same Origin Policy)? Yêu cầu tên miền chéo (cross-domain request) này có thể thực hiện được vì Facebook cho phép nó nhờ header có tên Access-Control-Allow-Origin hiện diện trong phản hồi .

Note: this authentication type should only be used if there is no other one. Indeed, it is the least secure because the authentication code will be exposed (and therefore vulnerable) to the client side .

Sequence diagram

3. Resource Owner Password Credentials Grant :

When should it be used ?

• With this type of authorization, a credential (password) is sent to the client and then to the authentication server. Therefore, it is imperative to have absolute trust between these two subjects. It is mainly used when the client has been developed by the same developer as the authentication server. For example, we can imagine a website named example.com looking for access to the protected resources of its own subdomain api.example.com . The user will not be surprised to enter his or her login / password on the website example.com since their account has been created on it.

For example :

• Resource owner: you have an account on the Acme company website acme.com .
• Resource Server: Acme Company disclosed its API at api.acme.com .
• Client: website acme.com from Acme company.
• Proxy server: an Acme server.

Situation :

• Acme Company, which is doing well, thinks it will provide a RESTful API for third-party applications.
• The company says it would be convenient to use its own API to avoid having to “reinvent the wheel”.
• The company needs an access token to call its own API methods.
• To do this, the company requires you to enter your login information through a standard HTML form as you normally would.
• The server side application ( acme.com website) will exchange your login information with the authentication code accessed from the authentication server (if your credentials are valid, of course).
• The application can now use the access authentication code to query its own resource server ( api.acme.com ).

Sequence diagram :

4. Vulnerability in Authorization Code Grant

When should it be used ?

• This permission type is used when the guest is the owner of the resource. There will be no authentication to retrieve from the end user.

For example :

• Resource owner: any website.
• Resource Server: Google Cloud Storage.
• Client: resource owner.
• Proxy server: a Google server.

Situation :

• The website stores its files on Google Cloud Storage.
• The site must go through the Google API to retrieve or modify the file and must authenticate with the authentication server.
• Once authenticated, the website will receive an access token that can now be used to query a resource server (Google Cloud Storage).

Ở đây, người dùng cuối không phải cấp quyền truy cập vào máy chủ tài nguyên.

Sequence diagram :

How to use the access authentication code (Access token usage):

The access token can be sent in many ways to the resource server. You can use GET or POST .

Example 1:

This is not ideal as the token can be found in the web server’s access log.

Example 2:

Authorization header

This looks better, but not all resource servers will accept this.

Security:

There are many opinions that criticize OAuth2 protocol for not meeting security standards. However, it often comes down to poor implementation of the protocol. Talking about security is not my strength, so this section I will only mention the gaps in the OAuth2 protocol and the related links for everyone to discuss further. Here are a few mistakes to avoid when using:

1. Authorization Code Grant More Infomation!
2. Implicit Grant vulnerability More Infomation!
3. ClickjackingMore Infomation!

Summary:

Like it or not, like it or not, everyone can see that OAuth2 seems to be seeing itself as a standard solution for decentralizing between different applications. In any case, I hope I’ve given you a little more perspective on how it works.

This is quite a long article. And I’m glad that people read to the very end of the article. Any shortcomings in the article, everyone can leave the comment below to comfortably rotate. Thank you very much. Link the original article on my blog!