This article takes github as an example to 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 saying “I have read” after reading the article, you can only leave a message when you find that you have the account of this website. At this time, you are given two choices: one is to register a new account on my website, and then use the registered user name to leave a message; One is to log in using your Github account and leave messages using your Github username. The former you feel too cumbersome, so inertia click the Github login button, at this time the OAuth authentication process begins.

To be clear, even if a user has just logged on to Github, it is not possible for my site to send a request to Github and get access to visitor information, which is obviously not secure. Even if a user gives you access to their information on Github, github does not allow you to do so. So there needs to be a negotiation between my site and Github before I can operate it.

1. Negotiation between the website and Github

Github classifies user permissions, such as the right to read warehouse information, the right to write to the warehouse, the right to read user information, the right to modify user information, etc. If I want to access user information, Github will require me to register an application on its platform, specify the permissions to access user information when applying, and fill in your website domain name when applying. Github only allows access to user information from this domain name.

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

2. Negotiation between users and Github

When a user enters my website and clicks the Github login button, my website will hand over the Client Id to the user and let him enter the Github authorization page. When github sees the ticket in the user’s hand, it knows that it is my website that let him come here. It then shows me the permissions my site wants and asks the user if they will allow me to get them.

/ / user logs in making, negotiate the GET / / github.com/login/oauth/authorize / / negotiation documents params = {client_id: "XXXX", redirect_uri: "http://my-website.com" }Copy the code

If the user thinks that my site wants too much permission, or does not want me to know his information at all, chooses to refuse, the whole OAuth 2.0 authentication will end, authentication also ended in failure. If the user is OK, clicking on the license page to confirm the license redirects to my pre-specified redirect_URI with a stamped ticket code.

// Negotiate successfully with a stamped code Location: http://my-website.com?code=xxxCopy the code

At this point, the negotiation between the user and Github is complete, and Github records the negotiation on its own system, indicating that the user has given permission to directly access and use some of his resources on my site.

3. Tell Github my site is coming to visit

In the second step, we have got the stamped ticket code, but this code only indicates that the user has allowed my website to obtain the user’s data from Github. If I directly take this code to Github to access the data, I will definitely be rejected, because anyone can hold the code. Github doesn’t know that CODE is owned by me.

Do you still remember the two tickets github gave me when I applied for the application? The Client Id has been used in the previous step, and then it is the turn of another ticket, Client Secret.

/ / negotiation between web sites and making POST / / github.com/login/oauth/access_token / / negotiation documents including making to cover chapter and making sent me tickets params = {code: "xxx", client_id: "xxx", client_secret: "xxx", redirect_uri: "http://my-website.com" }Copy the code

Go to Github with the user’s stamped code and client_ID and client_secret to get the final access_token.

/ / to get the final green card response = {access_token: "e72e16c7e42f292c6912e7710c838347ae178b4a scope" : "the user, the gist" token_type: "bearer", refresh_token: "xxxx" }Copy the code

4. Users started leaving messages on my page using their Github accounts

/ / GET access to user data / / api.github.com/user?access_token=e72e16c7e42f292c6912e7710c838347ae178b4aCopy the code

Last step, Github has given me the access_token of the last green card. By adding the API provided by Github and the green card, I can access the user’s information. What permissions can be obtained from the user are also clearly explained in response. Scope is user and gist, that is, only access to the user group and gist group of two groups, the user group contains the user name and email information.

Response = {username: "barretlee", email: "[email protected]"}Copy the code

The whole OAuth2 process has been basically completed here. The expression in the article is very rough. For example, the Access_token green card has an expiration date. The emphasis is on getting the reader to understand the whole process, and the details can be read in the RFC6749 documentation.

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