




















在 RFC6749 中,Implict Grant Flow的流程图比较复杂:
+----------+
| 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 |
| |
+---------+
但是实际应用中,我们通常只会采用 ABCG 四步,省略DEF。Implict Grant 是一种简化的授权流程,它的流程如下:

client_id, redirect_uri, scope, state, response_type 设置为 tokenredirect_uri,并且带上 access_token, state, expires_in 等至此,我们就已经拿到了 access_token,从而可以进行后续步骤。而RFC中,多出了 D、E两步,我们可以看一下RFC中的流程描述:
The flow illustrated in Figure 4 includes the following steps:
(A) The client initiates the flow by directing the resource owner's
user-agent to the authorization endpoint. The client includes
its client identifier, requested scope, local state, and a
redirection URI to which the authorization server will send the
user-agent back once access is granted (or denied).
(B) The authorization server authenticates the resource owner (via
the user-agent) and establishes whether the resource owner
grants or denies the client's access request.
(C) Assuming the resource owner grants access, the authorization
server redirects the user-agent back to the client using the
redirection URI provided earlier. The redirection URI includes
the access token in the URI fragment.
(D) The user-agent follows the redirection instructions by making a
request to the web-hosted client resource (which does not
include the fragment per [RFC2616]). The user-agent retains the
fragment information locally.
(E) The web-hosted client resource returns a web page (typically an
HTML document with an embedded script) capable of accessing the
full redirection URI including the fragment retained by the
user-agent, and extracting the access token (and other
parameters) contained in the fragment.
(F) The user-agent executes the script provided by the web-hosted
client resource locally, which extracts the access token.
(G) The user-agent passes the access token to the client.
See Sections 1.3.2 and 9 for background on using the implicit grant.
See Sections 10.3 and 10.16 for important security considerations
when using the implicit grant.
我们结合实际的例子,那就是在App里,使用Google帐号登录,那么就应该先弹出一个Webview才能进行URL跳转,所以结合这个例子,步骤就是:
实际上,我们可以把步骤D、E、F合并成一个步骤,也就是当授权服务器重定向回来时,我们就在该页面执行一段JS脚本,将 access_token 提取出来,然后使用JS Bridge,或者deeplink的方式将access token提交给App,这样就简化了整个流程。
Implict Grant Flow 的优点就是,简单,比起 Authorization Code Flow来说,少了很多步骤,但是缺点就是由于 access_token 是存放 在URL里,如果将URL分享出去了,那么拿到 access_token 就可以访问对应的资源,不是很安全。现在业界不是很推荐使用这种授权方式。
refs:
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。