利用 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:

相关文章