Briefly describe the operation process of OAuth 2.0

Quote: https://www.barretlee.com/blog/2016/01/10/oauth2-introduce/

This article will take the user's use of github to log in to the website and leave a message as an example to briefly describe the operation process of OAuth 2.0.

If I have a website, you are a visitor on my website, and you want to leave a message after reading the article to say "I have read it". When you leave a message, you find that you have an account on this website to leave a message. At this time, you are given two choices: one is to I have a new account registered on my website, and then use the registered user name to leave a message; one is to use the github account to log in, and use your github user name to leave a message. You think the former is too cumbersome, so you click the github login button habitually, and the OAuth authentication process begins.

It needs to be clear that even if the user has just logged in to github, it is impossible for my website to send a request to github to get the visitor information, which is obviously insecure. Even if the user allows you to get his information on github, github will not let you get it at will in order to ensure the security of user information. So before operation, there needs to be a negotiation between my website and github.

1. Negotiation between the website and Github

Github classifies the permissions of users, such as the permission to read repository information, the permission to write to the repository, the permission to read user information, the permission to modify user information, and so on. If I want to obtain user information, Github will ask me to first register an application on its platform, indicate which permissions need to obtain user information when applying, apply as many as needed, and fill in your application when applying Website domain name, Github only allows user information to be obtained in this domain name.

At this point, my website has reached a consensus with Github, and Github also sent me two tickets, one ticket is called Client Id, and the other ticket is called Client Secret.

2. Negotiation between user and Github

When the user enters my website and clicks the github login button, my website will give the user the Client Id obtained above and let him enter the authorization page of Github. Github sees the ticket in the user's hand and knows that this is me The website asked him to come over, so it put out the permissions that my website wanted to obtain, and asked the user whether to allow me to obtain these permissions.

// User logs in to github and negotiates 
GET //github.com/login/oauth/authorize 

// negotiation credentials 
params = { 
client_id: "xxxx", 
redirect_uri: "http://my-website.com" 
}

If the user feels that my website requires too many permissions, or does not want me to know his information at all, and chooses to refuse, the entire OAuth 2.0 authentication will end, and the authentication will also end in failure. If the user feels OK, after clicking Confirm Authorization on the authorization page, the page will jump to my pre-set ticket code with a stamp. redirect_uri

// After successful negotiation, with the stamped code 
Location: http: //my-website.com?code=xxx

At this time, the negotiation between the user and Github has been completed, and Github will also record this negotiation in its own system, indicating that the user has allowed to directly operate and use some of his resources on my website access.

3. Tell Github that my website is coming to visit

In the second step, we have obtained the stamped ticket code, but this code can only indicate that the user allows my website to obtain the user's data from github. If I directly use this code to go to github to access the data, it will definitely be blocked Rejected, because anyone can hold the code, github doesn't know that the code holder is me.

Remember the two tickets that github gave me when I applied for the application before, the Client Id has been used in the previous step, and the next ticket is the Client Secret.

// Negotiation POST between the website and github //github.com/login/oauth/access_token // Negotiation credentials include github's stamp to the user and the ticket github sent me params = { code: "xxx", client_id: "xxx", client_secret: "xxx", redirect_uri: "http://my-website.com" }

Take the code stamped by the user and the client_id and client_secret that can identify the individual to visit github, and get the final green card access_token.

// get the last green cardresponse 
= { 
 access_token: "e72e16c7e42f292c6912e7710c838347ae178b4a" 
scope: "user,gist" 
token_type: "bearer", 
refresh_token: "xxxx" 
}

4. User starts to leave comments on my page with github account

// Access user data 
GET //api.github.com/user?access_token=e 72e16 c 7e42f 292 c 6912e7710 c 838347ae 178b 4a

In the previous step, github has given me the last green card access_token. Through the API provided by github and the green card, I can access the user's information, and which permissions can be obtained from the user are also clearly explained in the response. The scope is user and gist. That is to say, only the permissions of the user group and the gist group can be obtained. The user group contains the user's name and mailbox and other information.

// tell me the user's name and email 
response = { 
 username: "barretlee", 
email: "[email protected]" 
}

The entire OAuth2 process is basically completed here. The expression in the article is very rough. For example, the green card access_token has an expiration time. If it expires, you need to use refresh_token to re-visit. The point is to let readers understand the whole process, and the details can be read in the RFC6749 document .

Hope it helps you understand OAuth 2.0. (End of this article)