本系列文之後也会置於个人网站

     +----------+
     | 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 |
     |         |
     +---------+

   Note: The lines illustrating steps (A) and (B) are broken into two
   parts as they pass through the user-agent.

                       Figure 4: Implicit Grant Flow

如果说password适用於原生应用环境(Native Application)下的话，接着就是适用於纯前端环境。
在现在前後分离架构的情况，前端与後端连接并不紧密，甚至前端几乎就可以视爲一个完整的应用。
因此将前端视爲授权框架下的「客户端(Client)」也就不会太难理解。

OAuth.tools环境设定

接着，要透过另外一个线上服务来学习隐含模式--OAuth.tools。

该服务似乎已经有针对Windows和Mac的应用，如果是使用下载版本，之後的内容可能与本系列会有些差异。(但体验可能较好？)

爲了让该服务能够与自架的Keycloak服务配合，需要做以下设定。

选择右上方 Environments

然後新增环境( New environment )，并填入相关内容。

相关设定可以先下载设定档，然後汇入。
目前设置爲私人，让我再想想怎麽处理。不过主要设定Authorization Endpoint和Token Endpoint应该足够。

设定Client

在这之後的内容，会透过这个工具和Keycloak、Curl及RESTer。

如果你是使用下载版，或许可以不需要使用Curl

现在，需要爲这个工具添加一个OAuth Client。在Keyclock新建一个Client -- oauth_tools，并注意Root URL设置爲https://oauth.tools

接着，将Access Type设定改爲confidential，并将所有模式打开。

按下储存後会出现Credential的页签，并将Secret设定的值复制下来。

最後，将OAuth.Tools环境也添加一个可用的Client。Secret填入刚刚复制的值。

开始学习Implicit Flow

连线设定

在左边选择 Demo: Implicit Flow ，并将环境设置爲刚刚所建立的。

第一个部分的URI是Web App接受处理存取权杖的地方。怎麽处理的後面会提到。现在要选的，只有将Client设置爲oauth_tools。另外，预设的scope可能也不合法，未来也会说明如何在keycloak设定可接受的scope值。但现在你可能需要将scope改爲profile email roles。最後你可以产生一个可选的Nonce值。

第二个部分的URL是Keycloak登入验证使用的。你可看到相关的Query参数有所设定，包含client_id、redirect_uri、scope，此外还有response_type、state、nonce。前三个设计是基本必须的，除了scope有那些可用外，response_type也与验证服务器有关。

取得存取权杖

按下Run以後，可能会被要求登入，之後会回到OAuth.tools。实际上在登入之後至少做了一次转址，转址的连接同样可以看到：

可以看到其实它转换到最上面提供的URI，并透过#锚点的方式传送存取权杖。这次拿到的存取权杖同样是Bearer类型，与昨天所差无几。不同的是这次并没有refresh_token。

在隐含模式的设计下，认爲资源拥有者使用浏览器与授权服务器保持着会话阶段。换句话说就是使用者登入中，所以可以随时取得新的存取权杖。

爲什麽叫隐含模式？

可以看到转址的URL是指定的客户端。在浏览器接受到这个讯息後，会发送一个请求给这个用户端，但不同的事情是现在真正的用户端应该是正在运行於浏览器的Web App本身，而不是提供Web服务的网页服务器。因此不应该将存取权杖发送到服务器，#锚点後的讯息应该被保留在浏览器里，甚至在浏览器网路工具中几乎也是隐藏的。

在「快速开始」的应用中，同样可以看到浏览器网址内保留了存取权杖的资讯，但在浏览器网路检查工具中，转址的结果却不一定看得到。

与Password Flow同样，这模式是如此简单。但将存取权杖暴露在使用者面前也不是非常好的做法，所以最好快速将讯息清除，或是转到其他页面。更好的或许应该选者其他模式，像是标准的Code Flow或是强化的PKCE。

(之後也许会在细谈该模式的风险所在)

参考资料

• OAuth 2.0 实战
• RFC6749