|
;| 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 添加 Authorizati |