• 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的实现也会复杂点。

  • 相关阅读:
    layui 自定义统一监听事件(大范围)
    layui 自定义个别事件
    Django layui {{ }}冲突解决方法
    sudo apt install ...
    Field XXX in XXXX required a bean of type XXXX that could not be found
    Springboot2+bootstrap-table1.12.1+MybatisPlus3.0 后台物理分页实现
    springboot2在后台打印系统执行的SQL
    @Service注解让spring找到你的Service bean
    接受参数的包装类的数据类型写错报错
    Java 日期转字符串
  • 原文地址:https://www.cnblogs.com/Code-life/p/9191374.html
Copyright © 2020-2023  润新知