In an article in the huawei account service learning notes (a) : what is the HMS, what is huawei account service “has been adjusted for everyone in huawei account service usage scenarios and advantages, then I will take you to learn more about huawei account service involves some basic knowledge, access method, productivity tools, etc. If you have any questions, feel free to leave them in the comments section.
To understand Huawei account service, first of all we need to be familiar with two protocols: OAuth2.0 and OpenID Connect protocol, because the login mode of Huawei account is based on these two protocols, not only Huawei account, WeChat and other manufacturers accounts are also based on these two protocols. This article starts with OAuth2.0.
First, an interesting question
Before I answer what OAuth2.0 is, I’ll throw out a question:
We know that the user can access their huawei or by means of account + password WeChat account details, such as user name, email, phone number, etc., but the third party App, such as the App under the wild motorcycle racing, users use the huawei account after logging in, the App won the user’s huawei account information, so it is how to obtain this information?
To answer this question, we need to introduce a concept: agency authorization; Agent authorization is a way to allow third-party applications to access user data. There are two ways:
1. Provide the user’s account and password to third-party applications so that they can log in to the account and access data on your behalf;
2. Authorize third-party applications to access the user’s data through OAuth without providing a password;
The first way is to believe that no user will accept, no user wants to expose their user name and password to others. The second method uses the OAuth protocol, it does not need to provide the user’s password to the third party, the third party can also get the required data, which is why we need OAuth.
Two, exactly what isOAuth2.0?
OAuth 2.0 is currently the most popular authorization mechanism for third-party applications to obtain user data. With OAuth2.0, the previous problem can be solved like this: the user gives limited authorization to the third-party application, and the third-party application can obtain authorized information from the server of the corresponding account through this limited authorization.
The design idea of OAuth2.0:
I have seen such a metaphor before, I think it can be very vivid description of the design idea of OAuth2.0, now take it to use, to facilitate everyone to quickly understand.
Courier and community access control system:
1, each community has access control system, enter a password to enter the community, only the owner knows the password
2. Couriers often enter the community to deliver express. Couriers have several ways to enter the community:
A. The owner tells the Courier the access control password, and the Courier enters by entering the password
B. The owner opens the door for the Courier remotely
C. Open up a new channel for couriers, which is only used to deliver couriers to designated locations:
— “Added” Request Authorization “button to the access control system
— “The Courier presses the button to ask the owner for authorization to enter
The owner agrees to return a “limited password” to the Courier after authorization.
The Courier can enter this password and enter the location where the express is delivered in the community, but cannot enter other places.
The first two ways are not optimal. First of all, the password of the community has many permissions, which makes it very unsafe for the Courier. Secondly, there may be many doors in the community, and the owner needs to open the door for the Courier every time he passes through the door, which is also very annoying. The C way is the best, and its design idea is used for the Internet, which is OAuth2.0.
Terms related to the OAuth2.0 protocol
Resource Owner: The user who owns the data that the client application wants to access.
Client: An application that wants to access user data
Authorization Server: Authorization Server that authorizes clients to access user data through user Authorization.
Resource Server: The system that stores the data to be accessed by the client. In some cases, the resource server and the authorization server are the same server.
Access Token: An Access Token is a unique key that a client can use to Access data authorized by the user on the resource server.
Scope: Authorization Scope that restricts what data the application can access about the user
The basic flow of OAuth2.0 protocol
Access Token and Password:
1, Access Token is the same as password, it is a certificate to obtain user data, leakage of AT and leakage of password have the same consequences
2. Access Token is short-term and will automatically expire when it expires. Users cannot modify it. Password is generally valid for a long time, do not modify will not change
3. Access Tokens can be revoked by the data owner with immediate effect, while passwords are generally not allowed to be revoked
4. Access Token has a Scope that specifies what the holder can only do, while the holder of the password has full permissions to do everything
The Access Token is designed to allow third-party applications to obtain the appropriate permissions, but it can be controlled at any time without compromising system security.
Four ways of OAuth 2.0
The first is mainly introduced here.
1, Authorization code)
Refers to that the client first obtains an authorization Code, and then exchanges the authorization Code for Access Token;
Usage scenario: The client has its own background server
Features: The authorization code is transmitted through the front end, while the AT is stored in the background server. The interaction with resources and authorization server is completed through the background server, and the front end is separated, which is very safe
2. Hidden
Usage scenario: pure front-end application, no back-end server
Features: Without authorization code, the AT is directly issued to the front end. The AT is stored in the front end, which is not very safe and suitable for scenarios with low security requirements
3. Code type
Usage scenario: A situation where the application is highly trusted and other authorization methods are not available
Features: The user directly tells the third party application the username and password, and the third party application uses your password to apply for the token
4. Certificate type
Usage scenario: a command line application without a front end
Features: Request tokens from the command line, and trust third parties directly
Access Token expired issue
The AT has an expiration date and needs to be reacquired after the expiration date.
Two ways:
1. The AT is acquired again according to the previous process, which is not good experience;
2. OAuth2.0 provides a way to return a Refresh Token AT the same time as the Access Token. When the Access Token expires, RT can be used to retrieve the AT.
The above is the content of OAuth2.0 that I want to share, hoping to bring benefits to everyone’s understanding. I’ll also share the OpenID Connect protocol next. We hope you will continue to pay attention to this account.
In the future, I will continue to output quality content in relevant fields. I hope you will continue to pay attention to this account!