Recent work encountered unauthorized access between multiple systems, to conduct a study and research OAuth2.0 and summarized notes.
[ Scene ]
We sign in a number of forums and other sites when you do not want a separate registration site account, you can choose to log in with a micro-channel or authorize QQ account. Such third-party login in the end is how to achieve it? Is our micro-channel Tencent QQ account information or sold to these sites? Obviously, Tencent is not so dry, login to achieve this, in fact, is the use of OAuth2.0 authorization login.
Similarly, within the company, if the companies have different sets of software systems, such as financial reimbursement system within the company network, time and attendance system, reimbursement system, personnel system, can achieve a staff account will be able to grant access to all systems, and each system does not need to open a separate account, set up a separate password. This is commonly referred to as SSO single sign-on, and OAuth2.0 is one way to achieve single sign-on .
[ Define ]
OAuth2.0 is a method that allows third-party applications that use the resource owner's credentials to obtain a license for limited access to resources.
For example, in the above example, by the process of micro-letter sign in the forum, the equivalent of micro-channel to allow the forum as a third-party application after authorization through micro-channel users, through the issuance of micro-channel authorization credentials limited access to user's micro letter head, phone number, gender and other resource-constrained, so log on to build their own logic.
Note: OAuth2.0 agreement, third-party applications to obtain credentials is not the same user name and password resource owners held to the example above, the micro-channel information is not directly user name, password, etc. as proof back to the Forum. This grant access to documents in general that represent a particular range, life cycle and its access to a string of visits by the token, that is, we often say that the token . In this mode protocol by introducing a OAuth2.0 authorization layer to the third-party applications and resource owners separation, and this authorization layer is often said that the " auth certification services / sso single sign-on server ."
The following roles are defined in four OAuth2.0 agreement:
1) Resource owner (resource owner)
That entity can grant the right to the protection of access to resources. For example, we use through micro-channel account login forum, but the actual owner of the account information is micro-channel micro-channel users, also known as end-users.
2) Resource Server (resource server)
The server hosting the protected resource can be received using the access token request to protected resources and in response, which may be the same server and authorization server ( "simplified model" described below), or may be different servers (below " authorization code mode "). The server role is micro-channel in the above example.
3) Client (client)
On behalf of the resource owner and authorized to issue an application for a protected resource requests. Forum user in the above example of the role is to be registered.
4) the Authorization Server (authorization server)
Authentication server, that service providers designed to handle authentication and authorization servers. WeChat open platform such as a server to provide authentication services.
[ Process ]
Or unauthorized access to the micro-channel example, the following process:
Flow Description:
- After the first micro-channel user clicks on Douban forum WeChat authorized login button, watercress network forum will request through URL redirection jump to the micro-channel user interface authorized manner;
- At this micro-channel user is actually carried out on a micro-channel authentication, there is no interaction with the watercress network forum, which is very similar to the shopping, use online banking to pay the scene;
- After you use the micro-channel client scan two-dimensional code authentication or enter a user name and password, micro-channel will verify the correctness of the user identity information, such as correct, it is considered the user to confirm the authorization micro-channel to log Douban forum, this time Mr. will become a temporary certificate , and carry this certificate by the user's browser will redirect the request back to the watercress network carry on the first redirect callBackUrl address;
- After the user's browser will carry a temporary credentials to access network services watercress, watercress network is through this scrip call micro-channel authorization interface again, get official access credentials the access_token ;
- After watercress acquired WeChat authorized access credentials the access_token, then the user authorization is substantially completed, subsequent watercress network to do is through this token then accesses the microcode believed to provide the relevant interface, obtain micro channel allows the user authorization information developed, such as avatar, nickname, etc., and accordingly complete its user logic and user login session logic.
【mode】
In the process of action is more crucial resource owner (the resource owner, user ) how can we give Client (Douban Forum) authorization, because only with this authorization, Client role before they can obtain an access token (access_token), then access to other resources through an interface token. And on the question of how to get the client's authorization, defined in OAuth2.0 the four kinds of Authorization , the current micro-letter unauthorized access, is one of the most common one used: "Authorization Code mode" (authorization_code).
OAuth2.0 defines four licensing model, they are:
- Authorization code pattern (authorization code)
- Simplified mode (Implicit)
- Password mode (resource owner password credentials)
- Client mode (client credentials)
Four modes comparative illustration:
1. authorization code pattern (authorization code)
The most complete, most rigorous process of licensing model, the most secure, and most commonly used.
Feature is the "Service Provider" certification service interaction (such as WeChat open platform) through the client's back-end server, such as micro-channel flow above account login watercress network is authorized to implement code pattern .
The process of authorizing the code is not the end client in this mode directly from the property owner, but as an intermediary to get through the authorization server (authorization server), authorized certification also authenticates the resource owner directly by authorization server, avoiding the resource owner credentials may be shared with the client, so it is very safe.
2. Simplified mode (implicit grant type)
简化模式是对授权码模式的简化，用于在浏览器中使用脚本语言如JS实现的客户端中，特点是不通过客户端应用程序的服务器，而是直接在浏览器中向认证服务器申请令牌，跳过了“授权码临时凭证”这个步骤。其所有的步骤都在浏览器中完成，令牌对访问者是可见的，且客户端不需要认证。如果使用此种授权方式来实现微信登录豆瓣网论坛的过程流程示例如下：
可以看出，与授权码模式的不同之处在于：在第4步用户完成授权后，认证服务器是直接返回了access_token令牌至用户浏览器端，而并没有先返回临时授权码code，然后由客户端的后端服务去通过授权码再去获取access_token令牌，从而省去了一个跳转步骤，提高了交互效率。
但是由于这种方式访问令牌access_token会在URL片段中进行传输，因此可能会导致访问令牌被其他未经授权的第三方截取，所以安全性上并不是那么的强壮。
3.密码模式（resource owner password credentials）
在密码模式中，用户需要向客户端提供自己的用户名和密码，客户端使用这些信息向“服务提供商”索要授权。这相当于在豆瓣网中使用微信登录，我们需要在豆瓣网输入微信的用户名和密码，然后由豆瓣网使用我们的微信用户名和密码去向微信服务器获取授权信息。
这种模式一般用在用户对客户端高度信任的情况下，因为虽然协议规定客户端不得存储用户密码，但是实际上这一点并不是特别好强制约束。就像在豆瓣网输入了微信的用户名和密码，豆瓣网存储不存储我们并不是很清楚，所以安全性是非常低的。因此一般情况下是不会考虑使用这种模式进行授权的。公司内网之间相互信任的子系统间也许才有可能使用。
如果使用此种授权方式来实现微信登录豆瓣网论坛的过程流程示例如下：
4.客户端模式（client credentials）
客户端模式是指客户端以自己的名义，而不是以用户的名义，向“服务提供方”进行认证。严格地说，客户端模式并不属于OAuth2.0协议所要解决的问题。在这种模式下，用户并不需要对客户端授权，用户直接向客户端注册，客户端以自己的名义要求“服务提供商”提供服务，其实不存在授权问题。
步骤如下：
(1)客户端向认证服务器进行身份认证，并要求一个access_token令牌。
(2)认证服务器确认无误后，向客户端提供访问access_token令牌。
(3)客户端后续携带access_token令牌继续后续业务请求流程。
步骤(1)中，客户端发出的HTTP请求，包含以下参数：
- grant_type：表示授权类型，此处的值固定为"client_credentials"，必选项。
- scope：表示权限范围，可选项。
示例：
POST /token HTTP/1.1
Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=client_credentials
认证服务器必须以某种方式，验证客户端身份。然后在步骤(2)中，认证服务器向客户端提供访问access_token令牌，下面是一个例子。
示例：
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache { "access_token":"2YotnFZFEjr1zCsicMWpAA", "iss":"签发授权者",
"sub":"服务使用者",
"aud":"服务提供者",
"exp":"过期时间", "iat":"签发时间", "other_custom_parameter":"value" }
综上所述，虽然在OAuth2.0协议中定义了四种客户端授权认证模式，但是实际上大部分实际应用场景中使用的都是授权码（authorization code）的模式，如微信开放平台、微博开放平台等使用的基本都是授权码认证模式。
【更新令牌】
如果用户访问的时候，客户端的"访问令牌"已经过期，则需要使用"更新令牌"申请一个新的访问令牌。
客户端发出更新令牌的HTTP请求，包含以下参数：
- grant_type：表示使用的授权模式，此处的值固定为"refresh_token"，必选项。
- refresh_token：表示早前收到的更新令牌，必选项。
- scope：表示申请的授权范围，不可以超出上一次申请的范围，如果省略该参数，则表示与上一次一致。
示例：
POST /token HTTP/1.1
Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA