前言

今天要看的 Implicit Grant，是 OAuth 2.0 核心規格（RFC 6749）裡四種基本 Grant Type 之一，也是目前官方明確建議不再使用的流程。它當年被設計出來，是為了解決純前端應用（像 SPA、一些原生 App）沒有安全地方保存 client_secret 的問題。不過，Implicit Grant 會直接透過瀏覽器 URL 回傳 Access Token，因此更容易在前端流程中外洩或遭到注入。為降低這些風險，RFC 9700 建議改用 Authorization Code Grant 搭配 PKCE；OAuth 2.1 草案也未再納入 Implicit Grant。

今天內容涵蓋:

1. Implicit Grant 是什麼
2. Implicit Grant 實際怎麼運作
3. Implicit Grant 的請求與回應參數
4. 為什麼不再建議使用

一、Implicit Grant 是什麼

Implicit Grant 是 OAuth 2.0 中一種直接核發 Access Token 的授權方式。使用者完成登入與授權後，Authorization Server 不會先回傳 Authorization Code，而是將 Access Token 放在 redirect_uri 的 URL Fragment 中，透過瀏覽器重新導向交給 Client。

這個流程最大的特徵，是省略了向 Token 端點交換 Authorization Code 的步驟。Client 在授權請求中使用 response_type=token，收到 Access Token 後便能直接呼叫 API，因此不需要後端參與。

Implicit Grant 當初主要是為了瀏覽器中的公開客戶端（Public Client）而設計，例如所有程式碼都執行於前端的 SPA。在 RFC 6749 發布時，瀏覽器直接呼叫 Token 端點的做法也尚未普及，因此直接回傳 Access Token 能降低實作門檻。不過，這也使 Token 必須經過瀏覽器前端，成為後續安全風險的來源。

二、Implicit Grant 實際怎麼運作

Implicit Grant 省略了 Token 端點的交換步驟。下圖先呈現完整流程，再依序說明每個步驟：

對照上圖，流程如下：

1. 使用者在 SPA 中點擊登入。
2. SPA 將瀏覽器重新導向 Authorization Server 的 /authorize 端點，並帶上 response_type=token、client_id、redirect_uri、scope 與 state。
3. Authorization Server 顯示登入與授權頁面。
4. 使用者完成身份驗證並同意授權。
5. Authorization Server 將 Access Token 放在 redirect_uri 的 URL Fragment（#）中，透過瀏覽器重新導向回傳給 SPA。
6. SPA 的前端程式從 URL Fragment 取出 Access Token。
7. SPA 在 HTTP Authorization Header 中攜帶 Access Token，呼叫 Resource Server 的 API。
8. Resource Server 驗證 Token 的簽章、期限、發行者與適用對象等資訊。
9. 驗證成功後，Resource Server 將受保護資源或 API 回應傳回 SPA。

圖中下半部的 a～c 是過去常見的「靜默重新授權（Silent Re-auth）」做法：Access Token 過期後，SPA 透過隱藏的授權請求，嘗試利用既有的瀏覽器 Session 取得新 Token。這不是 Implicit Grant 的必要步驟，而是早期用來補足「不能核發 Refresh Token」限制的替代方式。

三、Implicit Grant 的請求與回應參數

Authorization Request

Client 將瀏覽器導向 Authorization Server 時，會送出以下請求：

GET /authorize?response_type=token&client_id=abc123&redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback&scope=read&state=xyz HTTP/1.1
Host: as.example.com

Authorization Response

使用者完成登入與授權後，Authorization Server 透過重新導向回傳以下結果：

HTTP/1.1 302 Found
Location: https://app.example.com/callback#access_token=2YotnFZFEjr1zCsicMWpAA&token_type=Bearer&expires_in=3600&state=xyz

需要注意的是，RFC 6749 第 4.2.2 節規定 Authorization Server 不得在 Implicit Grant 中核發 Refresh Token；Access Token 過期後，Client 必須重新執行授權流程取得新的 Token。

四、為什麼不再建議使用

Implicit Grant 的核心問題，在於 Authorization Server 直接透過瀏覽器重新導向回傳 Access Token。這種做法雖然省略了 Code 交換，卻也讓 Token 更容易暴露在前端環境中。

與 Authorization Code + PKCE 的核心差異

SPA 與原生 App 的程式都執行在使用者裝置上，寫在程式裡的 client_secret 容易被查看或反編譯取得，因此不能可靠地證明 Client 身分。不過，這類 Client 仍可使用 Authorization Code + PKCE：Authorization Server 會先回傳一次性的 Authorization Code，再由 Client 搭配 PKCE 交換 Access Token。

Implicit Grant 的主要風險

1. Access Token 容易外洩： Token 直接出現在瀏覽器重新導向流程中，可能被瀏覽器歷史紀錄、惡意擴充套件、第三方程式碼或錯誤的重新導向設定取得。
2. 無法使用 PKCE： Implicit Grant 沒有 Authorization Code 的交換步驟，因此無法透過 code_verifier 將授權結果綁定到原本發起請求的 Client。
3. 無法核發 Refresh Token： Access Token 過期後必須重新執行授權流程。過去常見的隱藏 iframe 靜默授權又依賴瀏覽器 Cookie，在現代瀏覽器中已不再可靠。

⚠️ 現行建議： RFC 9700 建議一般情況改用 response_type=code，OAuth 2.1 草案也未再納入 Implicit Grant。因此，SPA 與原生 App 應採用 Authorization Code + PKCE；新系統不應再使用 Implicit Grant，既有系統則應規劃遷移。

小結

Implicit Grant 的核心，是讓 Authorization Server 在使用者完成登入與授權後，直接透過 redirect_uri 的 URL Fragment 回傳 Access Token。這種設計降低了早期瀏覽器公開客戶端的實作門檻，卻也使 Access Token 必須直接經過瀏覽器前端。

本文可以整理成三個重點：

• 流程特徵： Client 使用 response_type=token 發起授權，Authorization Server 直接在授權回應中核發 Access Token。
• 安全限制： Access Token 容易在瀏覽器流程中外洩或遭到注入，而且無法使用 PKCE，也不得核發 Refresh Token。
• 現行做法： RFC 9700 建議一般情況不要再使用 Implicit Grant；SPA 與原生 App 應改用 Authorization Code + PKCE，既有系統則應逐步規劃遷移。

下一篇將介紹 ROPC（Resource Owner Password Credentials）。Implicit Grant 的問題在於直接透過瀏覽器回傳 Access Token；ROPC 的問題則是要求使用者將帳號密碼直接交給 Client，兩者面臨的安全風險並不相同。

參考資源

• OAuth 2.0 Implicit Grant - oauth.net
• RFC 6749: The OAuth 2.0 Authorization Framework, Section 1.3.2 - RFC Editor
• Implicit Flow with Form Post - Auth0 Docs
• Implicit Flow - Logto Auth Wiki
• Implicit Grant - WSO2 Identity Server Documentation
• OAuth 2.0 implicit grant flow - Microsoft Entra
• OAuth 2.0 系列(4-2):Implicit Grant Flow - yorkxin's blog