In recent years, some apps and websites are increasingly able to access their site IDs, such as Naver, Google, Facebook, and KakaoTalk, rather than their own. It does not need to join unnecessary members when accessing through existing IDs of existing sites, and it also reduces the concern about information leakage due to weak security of small sites.
The basis of such a technique is defined by the OAuth 2.0 specification. Let’s look at an overview of its operation in this article.
Behavior of OAuth 2.0 and OAuth 2.0
Prior to the use of OAuth, each Web site was authenticated through its own authentication method, and the service was provided with authorization. As a result, all sites were using different authentication schemes, and the standard created to integrate them is OAuth.
(OAuth stands for Open Authorization, which started in 2006 and is now using OAuth 2.0.)
If any application or web site is implemented using Google OAuth 2.0, it will be able to authenticate via Google ID / Password and acquire related authority.
For an easy understanding, let’s look at an example of a flow of operations rather than a description of technology.
To help you understand, let’s take a look at the case of Google authenticating using OAuth 2.0 (Google ID) to use Memo application.
1. Tap the “Log in with Google ID” button on the side of the app to use the Memo app.
2. Memo app asks Google for “Request Token” and Google asks “Memo app” for “Request Token”.
3. The Memo application that receives the “Request Token” will go to the “Log in” page provided by Google, and he will authenticate by entering his Google ID and password here.
4. Once the verification is complete, Google will go back to the Memo app.
5. Memo app asks Google for “Access Token” and Google asks “Memo app” for “Access Token”.
6. The Memo application accesses Google’s user information and services using the “Access Token” it receives.
Large OAuth 2.0 flows follow the above path.
One thing to recognize here is that OAuth 2.0 is not a protocol that directly authenticates (authenticates). It allows each subject (Google, Naver …) to authenticate, and as a result, the token can be received and used to access user information or to use the service.
Again, OAuth 2.0 is a protocol for authorization, not an authentication protocol. Authentication is performed by each service provider in Step 3 above and is not directly related to the OAuth 2.0 protocol.
Based on the authentication performed by each service provider, the service can be used with the authorization (authorization) token.
OAuth 2.0 is not an authentication protocol.
[Note] Acknowledgment of difference between Authentication and Authorization
We talked a lot about Authorization and Authentication and tried to reduce confusion.
To get a clearer idea of the concept of OAuth 2.0, it is necessary to be clear about the difference between Authentication and Authorization. Briefly defined, Authentication is a method for Authorization.
One example is as follows.
When the user proceeds authentication through the input of the ID and password, he or she can authorize the target site (or app).
OAuth 2.0 helps existing users acquire privileges by using their own Naver, Google, etc. IDs without having to implement separate authentication. From the perspective of the users, it is possible to use it without any separate subscription, and it does not have to implement separate authentication for the application maker or web site operators.
However, one thing to know is that when an access token is created and made available through Google or Naver as above, some user information becomes accessible from the application or web site, so users need to recognize this part and use the service.