Understanding oauth 2.0

Oauth is an open network standard for authorization. It is widely used all over the world. The current version is version 2.0.

This article provides a concise and plain explanation of the oauth 2.0 design concept and operation process. The main reference material is RFC 6749.

I. Application scenarios

To understand the applicability of oauth, let me give a hypothetical example.

There is a "cloud printing" website that can print photos of users stored in Google. To use this service, you must allow "cloud printing" to read photos stored on Google.

The problem is that Google will accept "cloud printing" to read the photos only after being authorized by the user. Then, how does "cloud printing" obtain user authorization?

The traditional method is to tell your Google user name and password to "cloud printing", and the latter can read your photos. This practice has the following serious disadvantages.

(1) "cloud printing" will save the user's password for subsequent services, which is not safe.
(2) Google has to deploy Password Logon, but we know that simple Password Logon is not secure.
(3) "cloud printing" has the right to obtain all the information stored by users on Google, and users cannot limit the scope and validity of "cloud printing" authorization.
(4) only by changing the password can the user revoke the power granted to "cloud printing. However, this will invalidate all other third-party applications authorized by users.
(5) As long as a third-party application is cracked, the user password and all password-protected data will be leaked.

Oauth was born to solve these problems.

2. Glossary

Before explaining oauth 2.0 in detail, you need to know a few special terms. They are crucial to understanding the subsequent explanations, especially several images.

(1) third-party application: a third-party application, also known as "client" in this article, that is, "cloud printing" in the previous example ".
(2) HTTP service: HTTP service provider, referred to as "service provider" in this article, that is, Google in the previous example.
(3) resource owner: resource owner, also known as "user" in this article ).
(4) User Agent: user agent. This document describes the browser.
(5) Authorization server: authentication server, that is, the server dedicated by the service provider to process authentication.
(6) Resource server: The resource server that the service provider stores the user-generated resources. It can be the same or different server as the authentication server.

Once you understand the terms above, it is easy to understand that the role of oauth is to allow the "client" to securely and controllable access to "user" Authorization and interact with "service provider.

Iii. oauth ideas

Oauth sets an authorization layer between "client" and "service provider ). "Client" cannot directly log on to "service provider". You can only log on to the authorization layer to distinguish users from clients. The token used by the "client" to log on to the authorization layer, which is different from the user's password. You can specify the permission range and validity period of the token at the authorization layer during logon.

After the "client" logs on to the authorization layer, the "service provider" opens the user storage information to the "client" based on the permission range and validity period of the token.

Iv. Running Process

For example, the process of running oauth 2.0 is from RFC 6749.

(A) After the user opens the client, the client requires the user to authorize.
(B) The user agrees to authorize the client.
(C) The client uses the authorization obtained in the previous step to apply for a token from the authentication server.
(D) after the authentication server authenticates the client, it confirms the correctness and agrees to issue a token.
(E) The client uses a token to apply for resources from the resource server.
(F) The resource server confirms that the token is correct and agrees to open the resource to the client.

B is the key in the above six steps, that is, how the user can authorize the client. With this authorization, the client can obtain the token and then obtain the resource with the token.

The following describes the four authorization modes of the client.

V. client Authorization Mode

The client must be authorized by the user to obtain the access token ). Oauth 2.0 defines four authorization methods.

• Authorization code)
• Implicit)
• Resource owner password credentials)
• Client Credentials)

Vi. Authorization code mode

The authorization code mode is the most complete and rigorous authorization mode. It interacts with the "service provider" authentication server through the backend server of the client.

The procedure is as follows:
(A) when the user accesses the client, the latter directs the former to the authentication server.
(B) Select whether to authorize the client.
(C) assuming that the user is authorized, the authentication server directs the user to the "Redirect Uri" (redirection URI) specified in advance by the client and attaches an authorization code.
(D) The client receives the authorization code and attaches the previous "redirection Uri" to apply for a token from the authentication server. This step is completed on the backend server of the client, which is invisible to users.
(E) The authentication server checks the authorization code and redirect URI. After confirming the correctness, it sends the access token and the update token to the client ).

For example:

The Sina Weibo development platform uses the authorization code model.

 1 /** 2      * Executes 新浪微博 将用户导向认证服务器 action 3      * 4      * @param sfRequest $request A request object 5     */ 6     public function executeSina(sfWebRequest $request) 7     { 8         $code_url = $this->_sina_auth->getAuthorizeURL( $this->_sina_callback ); 9         $this->redirect($code_url);10     }

After the user gives authorization (redirect URI), the authentication server directs the user to the "Redirect Uri" (redirection URI) specified by the client in advance, and attaches an authorization code (CODE)

 1 /** 2      * Executes 新浪微博回调 action 3      * 4      * @param sfRequest $request A request object 5     */ 6     public function executeSinaCallback(sfWebRequest $req) 7     { 8         $code = trim($req->getParameter(‘code‘, ‘‘)); //授权码 9         if (isset($code)) {10             $keys = array();11             $keys[‘code‘] = $code;12             $keys[‘redirect_uri‘] = $this->_sina_callback;13             try {14                 $token = $this->_sina_auth->getAccessToken(‘code‘, $keys); //获取令牌15             } catch (Exception $e) {16                 17             }18         }19         if ($token) {20             //授权完成21             setcookie(‘weibojs_‘.$this->_sina_auth->client_id, http_build_query($token));22             //获取微博用户信息23             $c = new SaeTClientV2($this->_sina_app_id, $this->_sina_app_key, $token[‘access_token‘]);24             $uid_get = $c->get_uid();25             $uid = $uid_get[‘uid‘];26             $user_message = $c->show_user_by_id($uid);27             if(empty($user_message)) {28                 alertMsg2(‘获取微博用户信息失败‘);29             }30             //获取本地用户信息31             //$user_name = !empty($user_message[‘screen_name‘])?$user_message[‘screen_name‘]:$user_message[‘name‘];32             $user_name = $user_message[‘name‘];33             $result = $this->_writeSinaUserInfo($user_name,$user_message);34             if($result !== false) {35                 $this->redirect(‘@homepage‘);36             }37         } else {38             alertMsg2(‘授权失败‘);39         }40         $this->setLayout(false);41         return sfView::NONE;42     }

 

This article from: http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html

Understanding oauth 2.0