Oauth 2.0
2012年10月，OAuth 2.0 協議正式發佈為RFC 6749。現在百度開放平臺，騰訊開放平臺等大部分的開放平臺都是使用的OAuth 2.0協議作為支撐。
概述
OAuth是一個開放標準，允許用戶授權第三方應用訪問他們存儲在另外的服務提供者上的信息，而不需要將用戶名和密碼提供給第三方移動應用或分享他們數據的所有內容。
在OAuth 2.0的認證和授權的過程中主要包括以下角色定義：
- Resource owner： 資源所有者（通常指用戶或者提供資源服務的平臺）
- Resource server：資源服務器（託管受保護資源的服務器）
- Client：客戶端（瀏覽器、APP）
- Authorization server：授權服務器（頒發訪問令牌、驗證令牌、刷新令牌）
交互過程
OAuth 在 "客戶端" 與 "服務提供商" 之間，設置了一個授權層（authorization layer）。"客戶端" 不能直接登錄 "服務提供商"，只能登錄授權層，以此將用戶與客戶端區分開來。"客戶端" 登錄授權層所用的令牌（token），與用戶的密碼不同。用戶可以在登錄的時候，指定授權層令牌的權限範圍和有效期。"客戶端" 登錄授權層以後，"服務提供商" 根據令牌的權限範圍和有效期，向 "客戶端" 開放用戶儲存的資料。
以下為QQ的授權頁面，採用的是授權碼模式
- implicit：簡化模式，（不安全，適用於純靜態頁面應用）
- authorization code：授權碼模式（功能最完整、流程最嚴密的授權模式，通常使用在公網的開放平臺中）
- resource owner password credentials：密碼模式（一般在內部系統中使用，調用者是以用戶為單位。）
- client credentials：客戶端模式（一般在內部系統之間的API調用。兩個平臺之間調用。調用者是以平臺為單位。）
簡化模式
簡化模式適用於純靜態頁面應用。該模式下，access_token 容易洩露且不可刷新
- 用戶請求網站，如：www.tangyuewei.com
- 重定向到一個授權頁面
- 用戶同意授權
- 重定向到網站，並帶上access_token如：www.tangyuewei.com?access_token=123
- 獲取到資源服務器的資源
適用於有自己的服務器的應用，它是一個一次性的臨時憑證，用來換取 access_token 和 refresh_token。一旦換取成功，code 立即作廢，不能再使用第二次。
- 用戶請求網站，如：www.tangyuewei.com
- 重定向到一個授權頁面
- 用戶同意授權
- 重定向到應用的一個回調地址，如：www.tangyuewei.com/recieve_token?code=123
- 用code換取access_token和refresh_token
密碼模式
用戶向客戶端提供自己的用戶名和密碼，向 "服務商提供商" 換取 access_token 。
客戶端模式
如第三方，或者調用者是一個後端的模塊，沒有用戶界面的時候，可以使用客戶端模式。鑑權服務器直接對客戶端進行身份驗證，驗證通過後，返回 token。
接入公司內部系統
- 後臺管理系統
- 前臺業務系統
後臺管理系統
後臺系統之間資源互相訪問，如：日誌模塊，發郵件模塊，發短信模塊等（平臺資源）。
需要引用相關模塊的系統可採用客戶端模式授權
前臺業務系統
前臺系統之間資源互相訪問，如：用戶信息，模塊等（用戶資源）。
需要引用相關模塊的系統可採用密碼模式授權
綜合建議
綜合上述模式及認證流程，個人覺得以下場景可以考慮引入Oauth 2.0認證：
- 系統敏感資源服務進行安全認證及資源保護工作
- 多個服務的統一登錄認證中心、內部系統之間受保護資源請求
- 將受保護的用戶資源授權給第三方信任用戶
- 以後要做開發平臺類似百度開放平臺，騰訊開放平臺
閱讀更多 程序員諸葛 的文章
