Web验证方式(3)--OAuth 2.0协议

介绍

OAuth协议是用来解决第三方应用程序访问Http Service的时候的认证问题。举个例子：某视频网站支持用户通过微信登陆，然后获取用户在微信上的图像信息。

在这个场景里

　　微信充当的就是Http Service角色。

　　视频网站就是第三方应用

　　而视频网站从微信获取用户图像时，微信需要进行认证就是这里的认证问题

　　用户在微信上登陆后，产生的在视频网站中访问用户微信上的图像时所需的认证信息，就是OAuth解决认证问题的方式

名词定义

OAuth协议中定义了如下角色：

Resource Owner: 资源的所有者，比如此处的微信用户

Resource Server: 存储资源的服务器，比如此处的微信服务器

Authorization Server: 负责对用户验证并产生访问Resource Server时所需要的认证信息的服务器。

Client: 向Resource Server请求资源的应用程序。比如此处的视频网站。（网站后台）

User-Agent:用户代理，比如浏览器

总体流程

总体的认证流程如下：

　　　　　　　　　　　　　　　　　　   图1

A：Client向Resource Owner请求认证信息

B：Resource Owner提供认证信息(比如：用户名密码)

C: 将认证信息提交给Authorization Server进行认证

D：认证通过，Authorization Server返回Access Token

E:Client通过Access Token访问Resource Server中受保护的资源

步骤A，B中可以是发生在Client上,也可能是Client将用户导航到Authorization Server上进行。

步骤E中，根据Access Token的类型，Resource Server可能是自己验证，也可能是调用Authroization Server进行验证。

 

OAuth其实是创建了一个抽象层(Authorization Server)。

它主要负责两件事情：验证用户，产生统一的用于访问Resource Server验证信息。

验证的用户的方式可以是多种多样(用户名/密码, 手机验证码...)，因此这个抽象层将各种验证方式统一为此处的Access Token.这样对Resource Server屏蔽了用户验证的多样性，简化了逻辑。

授权模式

上面流程中最重要的其实是步骤ABCD，通过收集Resource Owner的认证信息，产生一个Access Token.这个过程称作Resource Owner对Client的授权。OAuth定义了四种授权模式：

授权码模式

简化模式

密码模式

Clent验证模式

 

授权码模式

流程图如下

授权码模式是四种模式中最严谨的一种。Client首先要到Authorization Server上注册，获取到一个Id.(这样只有被允许的Client才能通过OAuth进行验证，加强了安全性)

上面步骤中：

A Client将用户导航到Authorization Server的Authorize endpoint，同时带上clientId(这样Authorization Server可以对Client进行验证),认证结束后的跳转url.

Http请求如下：

GET https://sample.com/authroize?response_type=code&clientId=xxx&redirect_uri=https://www.client.com/oauthcallback.aspx

 

B 用户在Authroization Server的页面上输入自己的验证信息。

C Authorization Server通过导航用户到步骤A中指定的url,并将授权码以query string的形式提供。

Http Response信息如下：

HTTP/1.1 302 Found
Location: https://www.client.com/oauthcallback.aspx?code=xxx

 

D Client得到授权码后，调用Authorization Sever的接口(同时传入授权码和跳转URL，Authroization Server会对两者进行配对验证，以确保安全)

Http请求如下：

POST www.example.com/token 
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=xxx
&redirect_uri=https://www.client.com/oauthcallback.aspx

E Authorization Server返回Access Token给Client,Client存储下来，在后续请求中使用。

Response如下：

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
       "access_token":"2YotnFZFEjr1zCsicMWpAA",
       "token_type":"example",
       "expires_in":3600,
       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
       "example_parameter":"example_value"
}

 

在这个过程中，

1. Client没有接触到用户的验证信息(用户名/密码)

2. user-agent没有接触到Access Token。

3. 将授权码与跳转Url配对验证

这些都增强了整个过程的安全性。

简化模式

简化模式，是授权码模式的简化版。流程图如下：

 

这里和授权码模式的区别是：

1. 在步骤A中，直接请求的时token而不是code

GET /authorize?response_type=token&client_id=s6BhdRkqt3&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: www.example.com

 

2. 在步骤C中，Authorization Server直接在跳转url中附带上了access token,跳过了授权码这个环节。但是access token并非以query string的形式表示，而是以fragment(即url中的hash部分)

Http Response:

HTTP/1.1 302 Found
Location: http://client.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA&token_type=example&expires_in=3600

 

3. 根据http协议的定义，redirect时，fragment不会传到web服务器，因此client要想得到access token，必须在跳转url的response中返回一段js脚本来在浏览器中读到access token然后发送给client.(不太明白，OAuth中为什么要将access token放到hash中，而不是query string中)

密码模式

流程图如下：

密码模式中，Resource Owner直接在client的页面上输入认证信息。然后通过client来获取到access token.整个过程中client不能存储Resource Owner输入的认证信息。但是协议上没办法强制，只能依靠对client的信任了。因此这对Resource Owner来说是不那么安全的一种方式。

步骤B的请求如下：

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=password&username=johndoe&password=A3ddj3w

步骤C的Response如下：

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

 {
       "access_token":"2YotnFZFEjr1zCsicMWpAA",
       "token_type":"example",
       "expires_in":3600,
       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
}

Client验证模式

流程图如下：

 

其实这中方式应该不算是OAuth的适用场景里面的。这种模式下是用Client自身在Authorization Server上的认证信息来获取access token.也就是说把client当成一个resource owner,那么就和具体的使用client用户无关了。

扩展模式

采用什么方式获取到access token是通过token请求中的grant_type来确定的。因此Authorization Server可以通过这个字段来扩展更多的获取access token的方式。

 刷新Access Token

通过上述四种模式获得access token的时候，我们同时能获得一个refresh token。access token是有有效期的(e.g. 30分钟)。过了有效期后再使用就会报错。这个时候可以适用refresh token去找Authorization Server重新获取access token,这个过程不需要Resource Owner的参与，属于静默执行。

具体请求如下：

 

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA

 

 

 

验证Access Token

access token最后是发送给Resource Server的，所以Resource Server会对access token进行验证。而具体的验证方法取决与token的类型。

1. 如果token是一个不包含特定信息的字符串。Resource Server只能将这个token交给Authorization Server去解析拿到用户信息了。

2. 如果token是一个包含特定用户信息的字符串(e.g. jwt)。Resource Server则可以自行解析token拿到用户信息。

 

Authorization Server与Resource Server

Authorization Server和Resource Server可以是在同一台服务器上。也可以是在不同的服务器上。

1. 在同一服务器上

这种情况下第三方应用和HTTP Service其实是同一个应用，也就是任意的http应用自身的用户验证都可以应用OAuth协议。这种情况下，Authorization Server是应用的一个模块。

2. 在不同服务器上

这种情况的适用场景就比较多了。Authorization Server可以对应多个Resource Server,从而所有的Resource Server都可以把Authorization server 作为用户认证信息提供者。SSO，OPEN ID都可以用这种场景。

参考：RFC6749

CS模式应用采用OAuth

前面讨论的都是BS的Web应用。CS模式的应用(通信协议为Http)也是可以采用OAuth协议的。

以常见的app开发为例：

app的后台服务其实就是resource server,我们可以把authorization server单独部署或者和resource server一起部署，或者是后台服务的一个模块。但是由于app是自己开发的产品，属于可信任的client。因此可以采用密码模式。其他模式涉及url跳转，独立的验证页面等有点太复杂了。

不过如果app的后台要作为一个开放平台，供别的app调用，就需要支持其他模式了。因为跳转是发生在浏览器里的，因此这种情况下app的实现也会复杂点。