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:用户代理,比如浏览器

总体流程

总体的认证流程如下:

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

   图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验证模式

 

授权码模式

流程图如下

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

授权码模式是四种模式中最严谨的一种。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配对验证

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

简化模式

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

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

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

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中)

密码模式

流程图如下:

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

密码模式中,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验证模式

流程图如下:

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

 

其实这中方式应该不算是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的实现也会复杂点。

原文链接:https://www.cnblogs.com/Code-life/p/9191374.html

原创文章,作者:摘自网络,如若转载,请注明出处:https://www.15cov.cn/

本页面内容由网络采集 生成,若侵权请及时联系删除。1606107060@qq.com

发表评论

邮箱地址不会被公开。 必填项已用*标注