## 第二種方式：隱藏式 有些 Web 應用是純前端應用，沒有后端。這時就不能用上面的方式了，必須將令牌儲存在前端。**RFC 6749 就規定了第二種方式，允許直接向前端頒發令牌。這種方式沒有授權碼這個中間步驟，所以稱為（授權碼）"隱藏式"（implicit）。** **第一步**，A 網站提供一個鏈接，要求用戶跳轉到 B 網站，授權用戶數據給 A 網站使用。 ``` https://b.com/oauth/authorize?response_type=token &client_id=CLIENT_ID &redirect_uri=CALLBACK_URL &scope=read ``` 上面 URL 中，`response_type`參數為`token`，表示要求直接返回令牌。 **第二步**，用戶跳轉到 B 網站，登錄后同意給予 A 網站授權。這時，B 網站就會跳回`redirect_uri`參數指定的跳轉網址，并且把令牌作為 URL 參數，傳給 A 網站。 ~~~ https://a.com/callback#token=ACCESS_TOKEN ~~~ 上面 URL 中，`token`參數就是令牌，A 網站因此直接在前端拿到令牌。 >[danger]注意，令牌的位置是 URL 錨點（fragment），而不是查詢字符串（querystring），這是因為 OAuth 2.0 允許跳轉網址是 HTTP 協議，因此存在"中間人攻擊"的風險，而瀏覽器跳轉時，錨點不會發到服務器，就減少了泄漏令牌的風險。 這種方式把令牌直接傳給前端，是很不安全的。因此，只能用于一些安全要求不高的場景，并且令牌的有效期必須非常短，通常就是會話期間（session）有效，瀏覽器關掉，令牌就失效了