現在的互聯網流量入口基本上被幾大巨頭（BAT、TMD）所把持，對於新上線的應用獲取用戶比較快捷的方式就是通過OAuth2協議接入它們的賬號系統。降低用戶註冊&登錄成本，是大部分新上線應用的選擇。比如前段時間吵得沸沸揚揚的抖音濫用騰訊系（微信、QQ）用戶信息（頭像、暱稱）事件，就是因爲抖音上線時通過OAuth2接入了騰訊系的賬號體系，後面未經騰訊同意就將用戶信息給多閃使用。
本文將介紹OAuth2的四種授權模式，重點介紹授權碼模式。
下面以用戶在第三方應用訪問自己的照片列表爲例，分別介紹四種授權模式
授權碼（authorization-code）
特點
- 安全性高。是OAuth2四種模式中，安全性最高的一種
- 使用率高。據亞馬遜統計，互聯網上絕大部分應用都使用的是授權碼模式，如Facebook、GitHub、微信等
- 流程複雜。是四種模式中最複雜的一種
流程圖
詳細的授權流程說明
假設
- 第三方應用域名爲
https://a.com - 授權服務器域名爲
https://b.com
那麼授權流程爲：
-
瀏覽器訪問授權服務器請求授權
https://b.com/oauth/auth? response_type=code //表示使用授權碼模式 &client_id=CLIENT_ID //第三方應用註冊的id &redirect_uri=CALLBACK_URL //用戶授權後重定向的地址 &scope=read //授權範圍 -
用戶手動確認授權
-
授權服務器重定向到指定地址
https://a.com/callback?code=AUTHORIZATION_CODE //code就是授權碼 -
第三方應用拿到授權碼向授權服務器換取Token
https://b.com/oauth/token? client_id=CLIENT_ID //客戶端id &client_secret=CLIENT_SECRET //授權服務器的祕鑰 &grant_type=authorization_code //表示使用的是授權碼模式 &code=AUTHORIZATION_CODE //授權碼 &redirect_uri=CALLBACK_URL //回調的地址 -
當授權服務器校驗通過後會向指定的回調地址發送Token信息
{ "access_token":"ACCESS_TOKEN", "token_type":"bearer", "expires_in":2592000, "refresh_token":"REFRESH_TOKEN", "scope":"read", "uid":100101 }
問題
- 與授權服務器的通信協議必須是https嗎？
是的。oauth2規範中規定，授權服務器必須是通過加密的https協議進行通信，從而保證與授權服務器通信過程中不會被監聽 - 爲什麼不直接把Token直接給第三方應用，而是通過授權碼換區？
如果直接將Token給到瀏覽器且瀏覽器與第三方應用通信使用http通信，那麼Token將會被竊取且用戶無感知 - 既然Token會被竊取，那麼授權碼就不會被竊取嗎？
授權碼同樣有可能會被竊取。但OAuth2有這樣的規定，授權碼只能短期有效，且只能換取一次Token，如果獲此換取Token，那麼以最後一次換取的Token爲準。如果黑客在用戶之前通過授權碼換取了Token，那麼用戶通過授權碼換取Token時，黑客換取的Token將會失效。
簡化模式（implicit）
簡化模式是相對於授權碼模式來說，減少了通過授權碼換取Token的步驟
特點
- 簡單。流程簡單；
- 適用於純前端應用
- 不安全。稍有不慎，Token可以被惡意腳本獲取
- Token有效期短，瀏覽器關閉即失效
流程圖
問題
- 授權碼模式中說到直接返回Token不安全，爲什麼極簡模式可以直接返回Token？
返回的Token沒有放在queryString中，而是放在fragment（放在#後面）裏面。瀏覽器不會將fragment中的Token帶給後端，從而保證不會被別人劫持 - 授權服務器將Token返回到瀏覽器的過程會不會被別人監聽？
不會。因爲授權服務器強制使用https協議，所以不會被別人監聽
密碼模式（password）
特點
- 需要輸入賬號密碼，極度不安全，需要高度信任第三方應用
- 適用於其他授權模式都無法採用的情況
流程圖
憑證模式（client credentials）
特點
- 授權維度爲應用維度，而不是用戶維度。因此有可能多個用戶共用一個Token的情況
- 適用於應用維度的共享資源
流程圖
