OAuth 系列(三)簡化模式 Implicit

簡化模式 (Implicit) 也翻譯做隱式模式或者緊湊模式；

簡化模式的簡化是相對於授權碼模式來說的；

上篇文章 OAuth 系列(二)授權碼模式Authorization Code ；

我們講過要獲取 access_token 需要在 Client 服務器上發送 POST 請求；

但是在很多場景中我們可能沒有服務器只有瀏覽器；

在遠古時期還沒有 CORS；

為了向這類場景妥協；

在寫本文的時候我沒找到一個合適的簡化授權的示例網站；

於是我這裡在本地創建了一個 oauth 項目；

項目鏈接是 http://oauth.test

拼接鏈接

第一步都是拼接鏈接；

請求方式： GET

請求鏈接： http://oauth.test/oauth/authorize

並拼接攜帶以下參數：

response_type=token
client_id: xxx
redirect_uri: 

scope:
state: xxx

response_type 固定參數這裡就是 token ；

client_id 在平臺申請的 key；

redirect_uri 是當授權後的回跳鏈接；

scope 要申請的權限；

state 隨機生成的一個字符串是為了安全；

完整的鏈接就是這樣的了： http://oauth.test/oauth/authorize?response_type=token&client_id=xxx&redirect_uri=http%3A%2F%2Foauth.test%2Fauth%2Fcallback&scope=&state=xxx

獲取 token

1.當訪問上一步拼接好的鏈接時；

如果沒有登錄的話會先被重定向到登錄頁面；

http://oauth.test/auth/callback#access_token=xxx&token_type=Bearer&expires_in=31622400

token_type 是 token 類型一般是 Bearer ；

expires_in 過期時間

access_token 用於獲取用戶信息的令牌

我們可以看到這裡直接獲取到了 access_token ；

總結

簡化模式沒有獲取 code 的步驟；

整個過程我們只傳遞了 client_id ；

但是並沒有傳遞 client_secret ；

那麼也就無法驗證 client 的真實性；

獲得的 token 只有 access_token 沒有 refresh token；

而且 access_token 的過期時間設置的比較短；

因此現在不建議使用簡化模式；