JIYIK CN >

When I first came into contact with OAuth2.0, I often confused it with SSO single sign-on. Later, due to work needs, I implemented a set of SSO in the project. Through my gradual understanding of SSO, I also distinguished it from OAuth2.0. So at that time, I also compiled an article on the principle and implementation of SSO single sign-on

Recently, I need to connect with major e-commerce platforms frequently, so I met OAuth2.0 again. Therefore, I will sort out the principles and implementation methods of OAuth2.0 again here, hoping that this set of tutorials can help everyone. For a technical article, this introduction is a bit too long. Okay, let's get to the point.

What is OAuth2.0

OAuth is an open authorization protocol, which is currently the most popular authorization mechanism. It allows resources stored on one site to be shared to another site without using the credentials of that site.

This type of definition is generally quite abstract and difficult to understand. So here we use an analogy from a practical application to illustrate this scenario. You will find that the principle of OAuth2.0 is not complicated.

First, suppose I registered an account on WeChat, then added some friends, and had some chat records.

Then, I am visiting a website/app. Here, I assume that I am visiting www.jiyik.com . This website has a function that can obtain friends and chats on WeChat accounts, and then perform a statistical analysis on this information (of course, this website does not have this function).

I personally think this feature is good, so I want to use it. One way is that I can tell the app my personal WeChat account and password. The app can get friend information and chat history through the account and password. But I feel it is very unsafe. If I don't want to use it anymore, I have to change my account and password again. That would be very troublesome. So here I need a way to authorize some permissions to the website so that it can get this information without an account and password. This authorization method is OAuth2.0. When I no longer want to use this feature, I can revoke the permissions or invalidate the authorization.

Therefore, a complete OAuth2.0 process involves three entities.

• Resource service providers (WeChat, Google, Facebook, etc.)
• Third-party websites/apps
• user

When another third-party website wants to use a WeChat account to log in to its system, we can also log in to the third-party website through authorization. In this way, the same WeChat account can be used to log in to multiple different websites. This is also a single sign-on, which is why it is often confused with SSO at first .

Through the above scenarios, we can probably understand the basic principles of OAuth2.0. Next, we will introduce its architecture as a whole to have a deeper understanding of its working principle.

OAuth2.0 Architecture

This is the whole process.

1. First, users use third-party applications such as Google and WeChat to access resources.

2. The third-party website will redirect to the authorization login interface of the resource service with the client ID and client secret.

3. The user will receive a Google or WeChat authorization login interface where the user needs to authorize.

4. The user logs in using the authentication application. The client ID and client secret are unique to the client application on the authorization server.

5. The authentication server uses the authorization code to redirect the user to a redirection uniform resource identifier (URI). This address is submitted by the third-party website to the authentication service when accessing the resource service's authentication service. When the user successfully authorizes, he will be redirected to this URL.

6. The user visits the page located at the redirect URI in the client application, which now has a code for verification.

7. The client application will obtain the authentication code, client ID and client secret and send them to the authorization server.

8. The authentication application returns an access token to the client application.

9. Once the client application obtains the access token, the user starts using the client application to access the resource owner's resources.

The entire OAuth2.0 process is like this. This involves some HTTP knowledge points. For more information about HTTP, please refer to our HTTP tutorial .

OAuth2.0 involves many terms and concepts. Below we explain these terms and concepts.

the term

verify

Authentication is the process of identifying a user, usually based on the user's personal username and password. The username and password are used to verify whether the user is a legitimate resource holder.

Federated Identity

Many third-party websites/apps have their own usernames and passwords. Some applications rely on other services to verify the user's identity. A federated identity management system provides a single access to multiple systems. This is called federated identity.

Authorization

Authorization is the process of allowing someone to do something. It requires the identity of a valid user to check whether that user is authorized.

Delegation of authority

Delegation is the process of providing your credentials to another user to perform certain actions on that user's behalf.

Role

OAuth defines the following roles

• Resource Owner − A resource owner is defined as an entity that can grant the ability to access its own data hosted on a resource server. When the resource owner is an individual, it is called an end-user.
• Client Application - A client is an application that makes protected resource requests to perform actions on behalf of the resource owner.
• Resource Server - A resource server is an API server that can be used to access user information.
• Authentication Server - The authentication server obtains permission from the resource owner and issues access tokens to the client to access the protected resources hosted by the resource server.

Web Server

A web server is a computer system that delivers web pages to users using the HTTP protocol. Whenever an application wants to access a resource server, the client ID and secret key are stored on the web application server. The purpose of storing the client ID and secret key on the web application server is to keep it confidential.

In the above diagram, the resource owner allows a confidential client to access data hosted on a resource server, where the client ID and secret key are kept secret on the server.

The client ID and secret key are unique to the client application on the authorization server.

A resource server is a server that hosts resources such as Google and WeChat. These resources are stored on the resource server for access by client applications, and resource owners own these resources.

The authorization server then uses the client web application to access the resource owner's resources.

User Agent

The user agent application is used by the client application in the user's device. It can be a scripting language such as JavaScript running in the browser. So we can store the user agent application on the web server.

The following diagram shows the architecture of a client user agent application.

1. First, the user uses an authentication application such as Google or WeChat to access the resource owner's resources.

2. Next, the user application logs in to the authorization server by providing the client ID and client secret.

3. The user agent application then provides an instance of the JavaScript application running in the browser and connects to the web server.

Fourth, the authorization server allows access to resources from the resource server using the client credentials.

5. Resource servers contain resources owned by resource owners.

Native Applications

A native application can be used as an instance of a desktop or mobile application, which uses the resource owner credentials. It is a client application installed on the resource owner's device.

The authentication credentials used by the application are contained within the application code. Therefore, do not use native applications that run in an external user agent.

1. First, the user uses an authentication application such as Google or WeChat to access the resource owner's resources.

2. Next, the native application logs in to the authorization server using the client ID and client secret. A native application is an instance of a desktop or mobile application that is installed on the user's computer and stores the client secret on the computer or device.

3. The authorization server allows access to resources from the resource server using the client credentials.

4. Resource servers contain resources owned by resource owners.

Summarize

Above we introduced the overall process of OAuth2.0, as well as some of the terms and concepts involved. This requires us to have a little understanding of the principles of the HTTP protocol . From the above introduction, we can see that the core part of the whole process is the acquisition of the access token. In the next article, we will introduce in detail how to obtain the access token.