采纳 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 格兰特 (授权码认证)

   
授权码通过行使授权服务器做为客户端与资源所有者的中介而取得。客户端不是一向从资源所有者请求授权,而是指点资源所有者至授权服务器(由在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_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 格兰特模式获取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 格兰特 (是对 Authorization
Code 格兰特(Grant) 格局的简化)。
   
    先河化 OAuth2Controller 时, 只需向 OAuth2 Server 添加
AuthorizationCode 类型的授权即可,如下:
        $server->addGrantType(new
OAuth2\GrantType\AuthorizationCode($storage));

    Authorization Code 默认不辅助 Implicit 格兰特, 需要将 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 格兰特 (客户端凭证许可)

   
当客户端请求访问它所主宰的,或者事先与授权服务器协商(所利用的格局超出了本专业的限定)的别样资源所有者的受保障资源,客户端能够只利用它的客户端凭据(或者另外受援助的身份验证方法)请求访问令牌。

    客户端凭据许可类型必须只可以由秘密客户端接纳。

     +———+                                  +—————+
     |         |                                  |               |
     |         |>–(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/格兰特Types/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:

相关文章