OAuth 2 详解（二）：Implict Grant Flow
source link: https://jiajunhuang.com/articles/2022_10_09-oauth2_explained_implict_grant.md.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
OAuth 2 详解（二）：Implict Grant Flow
在 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 是一种简化的授权流程，它的流程如下：
- 用户点击登录
- 浏览器（或者App打开webview）重定向到Authorization Server，带上
client_id,redirect_uri,scope,state,response_type设置为token - Authorization Server 检测到用户没有登录或没有授权过，重定向到授权页面(如果没有登录，先到登录页)
- 用户同意授权
- Authorization Server 重定向回第2步设置的
redirect_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跳转，所以结合这个例子，步骤就是：
- 步骤A: App打开webview，将网页重定向到授权服务器，授权服务器展示授权页面
- 步骤B: 用户同意授权
- 步骤C: 授权服务器重定向回步骤A中给定的 redirect_uri，并且在URL中携带 access_token
- 步骤D: 由于这是一个浏览器页面，App无法直接将 access_token 返回给App，所以再次重定向到一个客户端获取access_token用的页面
- 步骤E: 该页面执行一段 JS 脚本，将 access_token 提取出来
- 步骤F: 返回给App
实际上，我们可以把步骤D、E、F合并成一个步骤，也就是当授权服务器重定向回来时，我们就在该页面执行一段JS脚本，将 access_token 提取出来，然后使用JS Bridge，或者deeplink的方式将access token提交给App，这样就简化了整个流程。
Implict Grant Flow缺点
Implict Grant Flow 的优点就是，简单，比起 Authorization Code Flow来说，少了很多步骤，但是缺点就是由于 access_token 是存放 在URL里，如果将URL分享出去了，那么拿到 access_token 就可以访问对应的资源，不是很安全。现在业界不是很推荐使用这种授权方式。
refs:
关注公众号，获得及时更新
Linux常用命令(一)：netcat 结合Flask 与 marshmallow快速进行参数校验 规整数据的重要性 apt安装特定包以及忽略升级某个包 Goroutine是如何处理栈的？ StackGuard的作用 Go DiskQueue源码阅读 NSQ源码分析 NSQ简明教程 结合Redis与MySQL实现又快又好的数据方案 程序员的MySQL手册(五)：索引优化 程序员的MySQL手册(四)：索引设计 程序员的MySQL手册(三)：数据库设计 Linux窗口管理器下的截图 Go设计模式：facade模式和观察者模式
Recommend
-
37
For the past few years, security research has been something I’ve done in my spare time. I know there are people that make a living off of bug bounty programs, but I’ve personally just spent a few hours here and there whe...
-
3
Not FoundYou just hit a route that doesn't exist... the sadness.LoginRadius empowers businesses to deliver a delightful customer experience and win customer trust. Using the LoginRadius Identity...
-
4
OAuth & Browserless Devices One of the last few legitimate usages of the Resource Owner Password Credentials (ROPC) grant type is for browserless devices, for example, a smart TV and other such Internet of Things (IoT) devices...
-
9
Don't use the OAuth password grant type Scott Brady 29 August 2017 ・ OAuth ・ Updated March 2022
-
7
Resource Owner Password Credentials grant flow in Azure AD Posted on: 05-05-2019
-
7
OAuth 2 详解（三）：Resource Owner Password Credentials Grant 这大概是最简单的一种授权方式之一了，那就是用户名密码授权。通常来说，是不建议使用，但是有一种情况下，非常适合：那就是 自家App对接的时候，这样就可以复用已有的授权逻辑。这种模式...
-
3
OAuth 2 详解（五）：Device Authorization Flow 我们经常可以看到这样的需求：智能电视要我们登录帐号，或者是命令行程序，需要登录帐号。提示通常都是：扫码或者打开网页 并且输入验证码后登录。这就是device authorization flow的流程了。 这个...
-
6
OAuth 2 详解（四）：Client Credentials Flow 这种模式，是另外一种简单的授权模式，甚至连用户名密码都不需要，直接根据 client_id, client_secret 就可以授权。
-
4
OAuth 2 详解（六）：Authorization Code Flow with PKCE 我们在前面了解到，Authorization Code 模式是最安全的一种模式，但是必须要有服务端参与进来，因为 client_secret 必须保存在 服务端才安全。OAuth 2.0 在
-
8
Learn how to use Proof Key for Code Exchange (PKCE) authentication flow to access APIs with your Swift iOS apps. Proof Key for Code Exchange (PKCE) is an addition to the OAuth authorization framework that protects...
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK