下 OAuth2-Server-php 在 Yii 框架上添建筑 OAuth2 Server

原文转自 http://www.cnblogs.com/ldms/p/4565547.html

 

Yii 有那么些 extension 可以以,在查看了 Yii 官网上供的及 OAuth
相关的扩充后,发现了几乎单 OAuth2 的客户端扩展,但是并不曾找到可以视作
OAuth2 Server 的恢宏。因为 Yii
是团队好的爱扩展的框架,所以完全可以合其它的 PHP OAuth2 Server
落实方案。在 OAuth.net/2/ 官网上,提供了几只 PHP 实现的 OAuth2
Server。这里用第一个 OAuth2-Server-php 来作 Yii 框架的 OAuth2 Server
扩展,需要开展有必需之构成操作,主要是编一个像样来领 client
访问同发布 access_token 等。

率先有些: 数据库准备

    OAuth2-Server-php  使用的数据库结构以 Github 上之
oauth2-server-php README.md 提供的说明结构(Schema),一共来五张表:

    mysql> show tables;
    +————————–+
    | Tables_in_oauth2         |
    +————————–+
    | oauth_access_token       |
    | oauth_authorization_code |
    | oauth_client             |
    | oauth_refresh_token      |
    | user                     |
    +————————–+
    5 rows in set (0.00 sec)
    
   
各表的名字说明了说明中存取的情节,表名可起定义,自定义位置吗:OAuth2/Storage/Pdo.php
48执之 config 数组中,因为此处以的凡 mysql 数据库,所以要改的凡
Pdo,若是以任何的囤方案,如
Redis,则自动修改对诺文件即可。注意这里的数据库名称是都是单数形式。

    使用以下 sql 语句创建这5个说明,并加上一个测试 client:
    ###############################
    ### oauth2 tables
    ###############################
    drop table if exists `oauth_client`;
    drop table if exists `oauth_access_token`;
    drop table if exists `oauth_authorization_code`;
    drop table if exists `oauth_refresh_token`;
    drop table if exists `user`;

    CREATE TABLE `oauth_client` (
    `client_id` VARCHAR(80) NOT NULL, 
    `client_secret` VARCHAR(80) NOT NULL, 
    `redirect_uri` VARCHAR(2000) NOT NULL, 
    CONSTRAINT client_id_pk PRIMARY KEY (client_id)
    );

    CREATE TABLE `oauth_access_token` (
    `access_token` VARCHAR(40) NOT NULL, 
    `client_id` VARCHAR(80) NOT NULL, 
    `user_id` VARCHAR(255), 
    `expires` TIMESTAMP NOT NULL, 
    `scope` VARCHAR(2000), 
    CONSTRAINT access_token_pk PRIMARY KEY (access_token)
    );

    CREATE TABLE `oauth_authorization_code` (
    `authorization_code` VARCHAR(40) NOT NULL, 
    `client_id` VARCHAR(80) NOT NULL, 
    `user_id` VARCHAR(255), 
    `redirect_uri` VARCHAR(2000), 
    `expires` TIMESTAMP NOT NULL, 
    `scope` VARCHAR(2000), 
    CONSTRAINT auth_code_pk PRIMARY KEY (authorization_code)
    );

    CREATE TABLE `oauth_refresh_token` (
    `refresh_token` VARCHAR(40) NOT NULL, 
    `client_id` VARCHAR(80) NOT NULL, 
    `user_id` VARCHAR(255), 
    `expires` TIMESTAMP NOT NULL, 
    `scope` VARCHAR(2000), 
    CONSTRAINT refresh_token_pk PRIMARY KEY (refresh_token)
    );

    — 
    CREATE TABLE `user` (
    `user_id` INT(11) NOT NULL AUTO_INCREMENT,
    `username` VARCHAR(255) NOT NULL, 
    `password` VARCHAR(2000), 
    `first_name` VARCHAR(255), 
    `last_name` VARCHAR(255), 
    CONSTRAINT user_pk PRIMARY KEY (user_id)
    );
    — test data
    INSERT INTO oauth_client (client_id, client_secret,
redirect_uri) 
        VALUES (“testclient”, “testpass”, “http://fake/”);
    INSERT INTO user (username, password, first_name, last_name) 
        VALUES (‘rereadyou’, ‘8551be07bab21f3933e8177538d411e43b78dbcc’,
‘bo’, ‘zhang’);

亚片: 认证方案及贯彻

    OAuth2 RFC 6749
规范提供了季种基本证明方案,以下针对当下四种植证方案和她在按部就班实现着之运方法进行个别说面。

先是种证明方法: Authorization Code Grant (授权码认证)

   
授权码通过应用授权服务器做呢客户端与资源所有者的中介如果博得。客户端不是一直由资源所有者请求授权,而是引导资源所有者及授权服务器(由当RFC2616中定义的用户代理),授权服务器之后引导资源所有者带在授权码回到客户端。

   
在引资源所有者携带授权码返回客户端前,授权服务器会评议资源所有者身份并获得该授权。由于资源所有者只及授权服务器进行身份验证,所以资源所有者的信不需要与客户端分享。

   
授权码提供了片重大之平安利益,例如验证客户端位的能力,以及朝客户端直接的拜访令牌的传而非经过资源所有者的用户代理来传送它要黑暴露于旁人(包括资源所有者)。

   
授权码许可类型用于取访问令牌和刷新令牌并未机密客户端进行了优化。由于当时是一个基于重定向的流水线,客户端必须能及资源所有者的用户代理(通常是Web浏览器)进行交互并能吸收来自授权服务器的扩散请求(通过重定向)。

  Authorization Code Grant 过程(又曰 Web Server Flow) 参见如下:
     +———-+
     | Resource |
     |   Owner  |
     |          |
     +———-+
          ^
          |
         (B)
     +—-|—–+          Client Identifier      +—————+
     |          +—-(A)– & Redirection URI —->|               |
     |  User-   |                                 | Authorization |
     |  Agent   +—-(B)– User authenticates —>|     Server    |
     |          |                                 |               |
     |          +—-(C)– Authorization Code —<|               |
     +-|—-|—+                                 +—————+
       |    |                                         ^      v
      (A)  (C)                                        |      |
       |    |                                         |      |
       ^    v                                         |      |
     +———+                                      |      |
     |         |>—(D)– Authorization Code ———‘      |
     |  Client |          & Redirection URI                  |
     |         |                                             |
     |         |<—(E)—– Access Token ——————-‘
     +———+       (w/ Optional Refresh Token)

   
注:说明步骤(A)、(B)和(C)的直线因为通过用户代理要吃分为两局部。
    图1:授权码流程

    在图1饱受所出示之流水线包括以下步骤:

   
(A)客户端通过为授权端点引导资源所有者的用户代理开始流程。客户端包括其的客户端标识、请求范围、本地状态与重定向URI,一旦访问给准(或拒绝)授权服务器将传送用户代理回到该URI。
   
(B)授权服务器验证资源拥有者的位置(通过用户代理),并规定资源所有者是否给予或拒绝客户端的走访请求。
   
(C)假设资源所有者许可访问,授权服务器使用前(在呼吁时要么客户端注册时)提供的重定向URI重定向用户代理回到客户端。重定向URI包括授权码和之前客户端提供的另地方状态。
   
(D)客户端通过包含上一样步着收取的授权码从授权服务器的令牌端点请求访问使牌。当发起呼吁时,客户端和授权服务器进行身份验证。客户端包含用于取授权码的重定向URI来用于证明。
   
(E)授权服务器对客户端进行身份验证,验证授权代码,并保管接收的重定向URI与当步骤(C)中用来重定向客户端的URI相匹配。如果经过,授权服务器响应返回访问令牌与可选的基础代谢令牌。

    过程实现:
    1.    client app 使用 app id 获取 authorization code:

   
www.yii.com/oauth2/index.php?r=oauth2/authroize&response_type=code&client_id=testclient&state=xyz

    返回:$authcode = authorization code.
    Tips:     authorization code will expired in 30s,可以修改
OAuth2/ResponseType/AuthorizationCode.php 中的 AuthorizationCode class
的构造方法配置参数来自定义 authorization_code 有效时间。
    client_id 是事先注册在本 Server
上之动名称,这属于客户端管住范畴。 
    这同样步要展开用户(资源所有者)登录 OAuth2 Server
来成功授权操作。用户登录属用户管理层面,不属 OAuth2 Server
中应编制的功效。
    用户登录后只是选好可以于 client app 开放之操作(授权)。
   
这同一步绑定过程被,从安全角度来设想应强制用户还输入用户名密码确认绑定,不要直接读取当前用户session进行绑定。 

    2. 获取 access_token:
       client app 使用 authorization code 换取 access_token

       curl -u testclient:testpass
www.yii.com/oauth2/index.php?r=oauth2/token -d
“grant_type=authorization_code&code=$authcode

       返回:
        成功:
        {“access_token”:”aea4a1059d3194a3dd5e4117bedd6e07ccc3f402″,
         “expires_in”:3600,
         “token_type”:”bearer”,
         “scope”:null,
         “refresh_token”:”269a623f54171e8598b1852eefcf115f4882b820″
        }

        失败:
        {“error”:”invalid_grant”,
         “error_description”:”Authorization code doesn’t exist or is
invalid for the client”
        }

    Tip: 本步骤需要采取客户端的 client_id 和 client_secret
以及达同步获取之 authorization_code 换取 access_code.
         access_tokne 有效期为 3600s, refresh_token 有效期为
1209600s,可以于 OAuth2/ResponseType/AccessToken.php 中的 AccessToken
class 中之构造函数配置中展开修改。
    
   

次种证方式: Implicit (隐式认证)
    
   
隐式授权类型为用来取访问令牌(它不支持批发刷新令牌),并针对了解操作实际重定向URI的公共客户端进行优化。这些客户端通常以浏览器被运用诸如JavaScript的脚本语言实现。

   
由于当下是一个根据重定向的流程,客户端必须能够和资源所有者的用户代理(通常是Web浏览器)进行相互并能够吸纳来自授权服务器的传入请求(通过重定向)。

   
不同为客户端独家要授权和看令牌的授权码许可类型,客户端收到顾令牌作为授权请求的结果。

   
隐式许可类型不分包客户端身份验证而据让资源所有者与和重定向URI的挂号。因为看令牌被编码到重定向URI中,它可能会见暴露被资源所有者及任何驻留于相同设备上之应用。

    采用Implicit Grant方式取Access
Token的授权验证流程又让称之为User-Agent
Flow,适用于所有无Server端配合的使(由于用往往在一个User
Agent里,如浏览器中,因此这仿佛使用在好几平台下以让称Client-Side
Application),如手机/桌面客户端程序、浏览器插件等,以及基于JavaScript等脚论客户端脚本语言实现之运用,他们的一个旅特点
是,应用无法妥善保管其行使密钥(App Secret Key),如果以Authorization
Code模式,则会有泄露其动密钥的可能性。其流程示意图如下: 

     +———-+
     | Resource |
     |  Owner   |
     |          |
     +———-+
          ^
          |
         (B)
     +—-|—–+          Client Identifier     +—————+
     |          +—-(A)– & Redirection URI —>|               |
     |  User-   |                                | Authorization |
     |  Agent   |—-(B)– User authenticates –>|     Server    |
     |          |                                |               |
     |          |<—(C)— Redirection URI —-<|              
|
     |          |          with Access Token     +—————+
     |          |            in Fragment
     |          |                                +—————+
     |          |—-(D)— Redirection URI —->|   Web-Hosted  |
     |          |          without Fragment      |     Client    |
     |          |                                |    Resource   |
     |     (F)  |<—(E)——- Script ———<|              
|
     |          |                                +—————+
     +-|——–+
       |    |
      (A)  (G) Access Token
       |    |
       ^    v
     +———+
     |         |
     |  Client |
     |         |
     +———+

     注:说明步骤(A)和(B)的直线因为经过用户代理要深受分成两部分。

     图2:隐式许可流程

    图2被之所示流程包含以下步骤:

   
(A)客户端通过为授权端点引导资源所有者的用户代理开始流程。客户端包括其的客户端标识、请求范围、本地状态与重定向URI,一旦访问于认可(或拒绝)授权服务器将传送用户代理回到该URI。
   
(B)授权服务器验证资源拥有者的地位(通过用户代理),并确定资源所有者是否授予或拒绝客户端的顾请求。
   
(C)假设资源所有者许可访问,授权服务器使用之前(在求时还是客户端注册时)提供的重定向URI重定向用户代理回到客户端。重定向URI在URI片段中隐含访问使牌。
   
(D)用户代理顺着重定向指示通往Web托管的客户端资源发起呼吁(按RFC2616该要不含有部分)。用户代理在该地保留有信息。
   
(E)Web托管的客户端资源归一个网页(通常是包含嵌入式脚本的HTML文档),该网页会访问包含用户代理保留的有的完好重定向URI并领包含在有被的走访令牌(和其它参数)。
   
(F)用户代理于该地执行Web托管的客户端资源提供的提访问令牌的脚本。
    (G)用户代理传送访问使牌被客户端。

     Tips: 1. 形似不待提供 client_secret,仅需
client_id,单用户同样需要说明。
       2. Implicit Grant Type 不支持
refresh_token(或只是活动实现)机制。
       3. THE FIRST TIME THE USER AUTHENTICATES YOUR APP USING IMPLICIT
GRANT FLOW STORE THE ACCESS TOKEN! Once you have the access token do not
try to re-authenticate. Your access token that you stored should
continue to work!
          一旦取得 access_token (存在于 redirect_uri 的 fragment 中,
即 uri 中的 # 部分),Client 需要好积存 access_token。
       4. 比较适用于 Client-Side
Application,如手机/桌面客户端程序、浏览器插件等

    oauth2-server-php 对本授权方式的落实如下:

    1. 这种授权法包含于 Authorization Code Grant (是针对 Authorization
Code Grant 方式的简化)。
   
    初始化 OAuth2Controller 时, 只待向 OAuth2 Server 添加
AuthorizationCode 类型的授权即可,如下:
        $server->addGrantType(new
OAuth2\GrantType\AuthorizationCode($storage));

    Authorization Code 默认不支持 Implicit Grant, 需要用 Server.php 第
104 行的 ‘allow_implicit’ 修改为 ‘true’ 以开启 Implicit 授权。

    2. 获取 access_token

   
http://www.yii.com/oauth2/index.php?r=oauth2/authorize&response\_type=token&client\_id=testclient&state=xyz&redirect\_uri=www.baidu.com

    参数: response_type=token (必须, 固定值)
             client_id (必须)
             redirect_uri 可选
             scope    可选
             state    推荐
    注意:response_type = token 而非是 code, 因为隐式授权请勿用取得
authorization code。
    返回:
        成功:
            需要用户先点击授权按钮。
            SUCCESS! Authorization Code:
www.baidu.com?#access_token=9f0c38b475e51ccd3

        出错: redirect_uri 与登记的 client redirect_uri 不匹配。
            {“error”:”redirect_uri_mismatch”,”error_description”:”The
redirect URI provided is missing or does not
match”,”error_uri”:”http:\/\/tools.ietf.org\/html\/rfc6749#section-3.1.2″}

    access_token 存在于 redirect_uri 中之有(fragment)中,
即‘#’符号之后,client 需要协调取部分被之 access_token
并留意保留。开发人员应留神,一些用户代理不支持于HTTP“Location”HTTP响应标头字段被富含部分有。这些客户端需要采用除3xx
重定向响应以外的其它方式来重定向客户端——-例如,返回一个HTML页面,其中富含一个有所链接到重定向URI的动作的“继续”按钮。
    

其三种植证明方法: Resource Owner Password Credentials
(资源所有者密码凭证许可)

   
资源所有者密码凭据许可类型适合给资源所有者和客户端有信任关系之情形,如设备操作系统或高等级特权采取。当启用这种许可类型时授权服务器应该特别关照且只有当其他流程都未可用时才可以。

   
这种许可类型适合给能赢得资源所有者凭据(用户称与密码,通常用交互的款式)的客户端。通过转移已囤积的证据至访问令牌,它呢用于迁移现存的利用如HTTP基本要摘要身份验证的直白身份验证方案的客户端至OAuth。

     +———-+
     | Resource |
     |  Owner   |
     |          |
     +———-+
          v
          |    Resource Owner
         (A) Password Credentials
          |
          v
     +———+                                  +—————+
     |         |>–(B)—- Resource Owner ——->|              
|
     |         |         Password Credentials     | Authorization |
     | Client  |                                  |     Server    |
     |         |<–(C)—- Access Token ———<|              
|
     |         |    (w/ Optional Refresh Token)   |               |
     +———+                                  +—————+

     图3:资源所有者密码凭据流程

     图3挨的所示流程包含以下步骤:

    (A)资源所有者提供被客户端它的用户称与密码。
   
(B)通过包含从资源所有者处接收到之凭证,客户端起授权服务器的令牌端点请求访问使牌。当发起呼吁时,客户端和授权服务器进行身份验证。

   
(C)授权服务器对客户端进行身份验证,验证资源所有者的凭,如果可行,颁发访问使牌。

    Tips: 客户端一旦获得访问令牌必须抛弃凭据。

oauth2-server-php 对 Resource Owner Password Credentials 的实现如下:

    1. 第一在 Oauth2Controller 的构造函数中添加对于 Resource Owner
Password Credentials 授权法的支持,加入以下代码:

    $server->addGrantType(new
OAuth2\GrantType\UserCredentials($storage));

    2. 获取 access_token :

    curl -u testclient:testpass
www.yii.com/oauth2/index.php?r=oauth2/token -d
‘grant_type=password&username=rereadyou&password=rereadyou’

    返回:
        {“access_token”:”66decd1b10891db5f8f63efe7cc352ce326895c6″,
         “expires_in”:3600,
         “token_type”:”bearer”,
         “scope”:null,
         “refresh_token”:”b5fa0c24e786e37e7ce7d6e2f911805dc65a0d7c”}

    Tips:    Github 上 oauth2-server-php 提供的 sql schema user
表里面没有 user_id 字段[12],需要自行添加该字段(主键,
auto_increment)。
        user 表设计以 sha1 摘要方式,没有增长 salt。
        
        在 Pdo.php 中有:
        // plaintext passwords are bad!  Override this for your
application
        protected function checkPassword($user, $password)
        {
            return $user[‘password’] == sha1($password);
        }
        对于用户征需要改写这个函数。

季种植证明方法: Client Credentials Grant (客户端凭证许可)

   
当客户端请求访问它所决定的,或者先与授权服务器协商(所采取的章程超出了按专业之限量)的旁资源所有者的为保障资源,客户端好单独使它的客户端凭据(或者其他被支持之身份验证方法)请求访问使牌。

    客户端凭据许可类型必须只能由地下客户端采用。

     +———+                                  +—————+
     |         |                                  |               |
     |         |>–(A)- Client Authentication —>| Authorization
|
     | Client  |                                  |     Server    |
     |         |<–(B)—- Access Token ———<|              
|
     |         |                                  |               |
     +———+                                  +—————+

     图4:客户端凭证流程

     图4中的所示流程包含以下步骤:

    (A)客户端和授权服务器进行身份验证并向令牌端点请求访问使牌。

    (B)授权服务器对客户端进行身份验证,如果可行,颁发访问使牌。

     Tips: 这是绝简便易行的证明方式。

     由于客户端身份验证被看做授权许可,所以不欲外授权请求。

    实现如下:
    1. 每当 Oauth2Controller 中补充加对 client credentials
认证方式的支撑:

    $server->addGrantType(new
OAuth2\GrantType\ClientCredentials($storage));
    
    2. 获取 access_token:

    curl -u testclient:testpass
www.yii.com/oauth2/index.php?r=oauth2/token -d
‘grant_type=client_credentials’
    
    提交参数: grant_type    REQUIRED.  Value MUST be set to
“client_credentials”.
           scope    OPTIONAL.  
    返回:
        {“access_token”: “f3c30def0d28c633e34921b65388eb0bbd9d5ff9”,
         “expires_in”:3600,
         “token_type”:”bearer”,
         “scope”:null}

    Tips: Client 直接采用好之 client id 和 client_secret 获取
access_token;
          RFC6749规范指明[10] clinet crendentials 客户端认证取得
access_token 时未包 refresh_token。
          不过,oauth2-server-php 提供了控制开关,在
OAuth2/GrantTypes/ClientCredentials.php 第 33 行[11],
          默认 $includeRefreshToken = false; 设置也 true, 则可于通告
access_token 同时公布 refresh_token。
    

其三有: access_token 类型说明
    客户端在操作数据资源时(通过 api)需要为 server 出示
access_token,关于怎样展示 access_token 和 access_token
类型由以下一些说明。
    IETF rfc 6749 中证实的 access_token 类型有点儿栽:Bearer type 和 MAC
type。
    由于 OAuth2-Server-php 对于 MAC 类型的 access_token
尚在支付中,以下就对最常使用的 Bearer 类型 access_token 进行求证。

    有三栽在资源要中发送 bearer access_token
资源为资源服务器的办法[13]。客户端不克于历次要被使用超过一个方传输令牌。
    a.
当在由HTTP/1.1[RFC2617]概念之“Authorization”请求头部字段中发送访问令牌时,客户端采用“Bearer”身份验证方案来传访问使牌。

        GET /resource HTTP/1.1
        Host: server.example.com
        Authorization: Bearer mF_9.B5f-4.1JqM

   
客户端应该用含“Bearer”HTTP授权方案的“Authorization”请求头部字段发起带有不记名令牌的身份验证请求。资源服务器必须支持之措施。
    
    b. 表单编码的主脑参数
      
当在HTTP请求实体中心中发送访问令牌时,客户端应用“access_token”参数为请求主体中长访问使牌。客户端不可知利用此道,除非符合下列所有规则:
      
HTTP请求的实体头部含有设置也“application/x-www-form-urlencoded”的“Content-Type”头部字段。
      
实体中心遵循HTML4.01[W3C.REC-html401-19991224]概念之“application/x-www-form-urlencoded”内容类型的编码要求。
       HTTP请求实体中心是纯粹的局部。
       在实体中心中编码的情节要完全由ASCII[USASCII]字符组成。
      
HTTP请求方法是要主体定义为夫定义之语法。尤其是,这表示“GET”方法无克让以。
       
       客户端采用传输层安全发起如下的HTTP请求:
        
        POST /resource HTTP/1.1
        Host: server.example.com
        Content-Type: application/x-www-form-urlencoded
        access_token=mF_9.B5f-4.1JqM

    c.
当以HTTP请求URI中发送访问令牌时,客户端采用“access_token”参数,向“统一资源标示符(URI):通用语法”RFC3986概念之求URI查询部分添加访问使牌。

       例如,客户端采用传输层安全发起如下的HTTP请求:

        GET /resource?access_token=mF_9.B5f-4.1JqM HTTP/1.1
        Host: server.example.com

      
它不该于下,除非无克以“Authorization”请求头部字段或HTTP请求实体中心中传访问使牌。
    
    以上在 rfc6750 规范被提出的老三种 access_token
的使方法。推荐用第一种方案。Bearer token 的下得依赖 TLS 来确保
access_token 传输时的安全性。

季有: 使用 Bearer access_token 的调用 api

    1. 使用 refresh_token 换取 access_token:
     curl -u testclient:testpass
www.yii.com/oauth2/index.php?r=oauth2/token -d
“grant_type=refresh_token&refresh_token=1ce1a52dff3b5ab836ae25714c714cb86bf31b6f”

    返回: 
        {“access_token”:”50540a7ead3a27cdb458b6cdc38df25f64da18f1″,
         “expires_in”:3600,
         “token_type”:”bearer”,
         “scope”:null}
        这里没新的 refresh_token,需要开展配备为重得到
refresh_token,可修改 OAuth2/GrantType/RefreshToken.php 中的
RefreshToken class __construct 方法中的
‘always_issue_new_refresh_token’ => true 来开启颁发新的
refresh_token。
    Tips: IETF rfc2649 中对于 refresh_token section 的有说明,
        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

    需要提供客户端的 client_id 和 client_secret, grant_type 值必须是
refresh_token。
    access_token 有效期内无克以 refresh_token 换取新的
access_token。

    2. 使用 access_token:
    a. client app 使用 access_token 获取 resource 信息。
    oauth2-server 验证 access_token:
        curl www.yii.com/oauth2/index.php?r=oauth2/verifytoken -d
‘access_token=aea4a1059d3194a3dd5e4117bedd6e07ccc3f402’

    返回:
        {“result”:”success”,
         “message”:”your access token is valid.”
        }    这个片段只有是为证明 access token 的灵光,client app
并无该直接调用该法,而是在求资源时有server自行调用,根据判断结果开展不同处理。
    可以于 Oauth2 extension 之 Server.php 中来窜 access_token
的有效期。

    3. scope
    scope 需要服务端确定具体的管事操作。
    scope 用来规定 client 所能够进行的操作权限。项目蒙操作权限由 srbac
进行控制, Oauth2 中暂时不举行拍卖。

    4. state
    state 为 client app 在率先步骤中获得 authorization code 时于 OAuth2
Server 传递并由 OAuth2 Server 返回的自由哈希参数。state
参数主要为此来防护超越站点请求伪造(Cross Site Request Forgery,
CSRF),相关讨论可参见本文最后之参照【7】和【8】。

    
References:

相关文章