利用 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
扩大,要求展开一些少不了的构成操作,紧假诺编辑1个类来接受 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 语句成立那陆个表,并累加2个测试 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 瑞虎FC 6749
规范提供了五种为主评释方案,以下针对那五种讲明方案以及它们在本完结中的使用方式展开分级说面。

首先种注解方法: Authorization Code Grant (授权码认证)

   
授权码通过行使授权服务器做为客户端与财富全部者的中介而取得。客户端不是平昔从财富全部者请求授权,而是辅导能源全数者至授权服务器(由在RubiconFC2616中定义的用户代理),授权服务器之后辅导能源全数者带着授权码回到客户端。

   
在指点能源全数者引导授权码再次来到客户端前,授权服务器会鉴定财富全部者身份并获取其授权。由于能源全部者只与授权服务器进行身份验证,所以能源全部者的凭证不需求与客户端分享。

   
授权码提供了部分相当首要的平安利益,例如验证客户端身份的力量,以及向客户端直接的拜会令牌的传导而非通过能源全数者的用户代理来传送它而神秘暴光给外人(包含能源全部者)。

   
授权码许可类型用于获取访问令牌和刷新令牌并未机密客户端举行了优化。由于那是3个依照重定向的流水线,客户端必须可以与财富全数者的用户代理(平时是Web浏览器)举行交互并可以接收来自授权服务器的传播请求(通过重定向)。

  Authorization Code 格兰特 进程(又称作 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)客户端通过向授权端点指引能源全部者的用户代理起头流程。客户端包罗它的客户端标识、请求范围、本地处境和重定向UQashqaiI,一旦访问被批准(或拒绝)授权服务器将传送用户代理回到该U奥迪Q5I。
   
(B)授权服务器验证财富拥有者的地位(通过用户代理),并分明能源全体者是还是不是予以或拒绝客户端的造访请求。
   
(C)倘诺财富全体者许可访问,授权服务器使用此前(在哀求时或客户端注册时)提供的重定向ULANDI重定向用户代理回到客户端。重定向U奥迪Q5I蕴含授权码和后边客户端提供的其余地点情形。
   
(D)客户端通过包罗上一步中收到的授权码从授权服务器的令牌端点请求访问令牌。当发起呼吁时,客户端与授权服务器进行身份验证。客户端包括用于获取授权码的重定向UXC60I来用于注脚。
   
(E)授权服务器对客户端举办身份验证,验证授权代码,并确保接收的重定向UQX56I与在步骤(C)中用于重定向客户端的U讴歌MDXI相匹配。借使经过,授权服务器响应再次回到访问令牌与可选的基础代谢令牌。

    进程完毕:
    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 (隐式认证)
    
   
隐式授权类型被用于获取访问令牌(它不扶助批发刷新令牌),并对了然操作实际重定向U途睿欧I的集体客户端举行优化。这个客户端常常在浏览器中使用诸如JavaScript的脚本语言已毕。

   
由于那是三个依据重定向的流水线,客户端必须可以与财富全体者的用户代理(寻常是Web浏览器)举办互动并可以接受来自授权服务器的扩散请求(通过重定向)。

   
不一致于客户端独家请求授权和做客令牌的授权码许可类型,客户端收到访问令牌作为授权请求的结果。

   
隐式许可类型不含有客户端身份验证而借助于能源全部者在场和重定向UQashqaiI的注册。因为访问令牌被编码到重定向ULX570I中,它或然会暴露给能源全数者和此外驻留在相同设备上的利用。

    采纳Implicit 格兰特格局赢得Access
Token的授权验证流程又被称之为User-Agent
Flow,适用于拥有无Server端同盟的行使(由于采纳往往位于三个User
Agent里,如浏览器里面,由此那类应用在少数平台下又被叫做Client-Side
Application),如手机/桌面客户端程序、浏览器插件等,以及基于JavaScript等脚本客户端脚本语言完结的接纳,他们的2个手拉手特征
是,应用不能妥善保管其采纳密钥(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)客户端通过向授权端点指点财富全数者的用户代理先导流程。客户端包含它的客户端标识、请求范围、本地景况和重定向U大切诺基I,一旦访问被认可(或拒绝)授权服务器将传送用户代理回到该U汉兰达I。
   
(B)授权服务器验证能源拥有者的身份(通过用户代理),并规定财富全数者是或不是授予或拒绝客户端的访问请求。
   
(C)如若资源全数者许可访问,授权服务器使用从前(在伸手时或客户端注册时)提供的重定向UTiguanI重定向用户代理回到客户端。重定向U途达I在U科雷傲I片段中富含访问令牌。
   
(D)用户代理顺重视定向提示向Web托管的客户端财富发起呼吁(按本田UR-VFC2616该请求不包罗部分)。用户代理在当地保留部分音信。
   
(E)Web托管的客户端能源重回1个网页(平日是富含嵌入式脚本的HTML文档),该网页可以访问包括用户代理保留的一部分的全部重定向U冠道I并领取包涵在有的中的访问令牌(和其余参数)。
   
(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 格兰特 形式的简化)。
   
    早先化 OAuth2Controller 时, 只需向 OAuth2 Server 添加
AuthorizationCode 类型的授权即可,如下:
        $server->addGrantType(new
OAuth2\GrantType\AuthorizationCode($storage));

    Authorization Code 默许不扶助 Implicit 格兰特, 须求将 Server.php 第八4 行的 ‘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页面,其中饱含一个颇具链接到重定向UHighlanderI的动作的“继续”按钮。
    

其三种声明方法: 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;
          奇骏FC6749规范指明[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请求U奥迪Q5I中发送访问令牌时,客户端应用“access_token”参数,向“统一财富标示符(URI):通用语法”凯雷德FC3986概念的伸手U奇骏I查询部分添加访问令牌。

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

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

      
它不应该被运用,除非无法在“Authorization”请求底部字段或HTTP请求实体宗旨中传输访问令牌。
    
    以上在 rfc6750 规范中提出的二种 access_token
的应用办法。推荐应用第1种方案。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,
CS中华VF),相关啄磨可参见本文最终的参考【7】和【8】。

    
References:

相关文章