設計（OAuth2）訪問令牌

Question

我們計劃實施OAuth2規範並正在審查「訪問令牌」實施。 貌似規範給出了一個很大的自由去實現者，我們正在尋找 的一些最佳做法：

1. 要放什麼東西在訪問令牌？我們希望在尺寸和實用性之間取得良好的平衡。 我意識到這是非常特定的應用程序，但也許有一些事情值得擁有。

到目前爲止，我們確定了以下字段：

• 用戶識別
• 截止日期
• 版本（這樣我們就可以改變未來的格式）
• 客戶標識符（即應用程序誰請求令牌）

一些額外的屬性（例如。密碼散列）將被存儲在數據庫中，並在 認證期間（使用令牌中的字段作爲「密鑰」）進行查找。

1. 如何保護它？

我們傾向於安全地簽署訪問令牌（HMAC），以便我們知道它是否被篡改。 令牌中的字段隨後可供所有人閱讀。

另一種方法是加密（AES）整個事情，並使其對用戶完全不透明。這使得 它更大（以字節計）。它看起來像FB現在使用加密令牌（http://developers.facebook.com/blog/post/572/）

有關行業最佳實踐的任何建議？

感謝， 彼得

Answer 1

只要你可以映射訪問令牌你在後臺發出回用戶與到期日一起等，那麼它其實並不重要它是如何產生的（除了那個以外不應該是可預測的）。該規範沒有指定實現細節。

令牌可以是映射到後端用戶狀態的唯一生成的字符串，也可以將用戶信息和過期日期等加密到令牌本身中，在這種情況下考慮SWT。 SWT格式完全定義你描述的內容。它包含有關用戶，clientId，範圍等明文內容的信息，但隨後還提供了一個加密密鑰以使其防篡改。有了共享密鑰，即使是在另一臺服務器上或另一方產生密鑰，也可驗證該密鑰。他們往往會變得非常大，所以不理想的傳遞查詢字符串。

有一些基於雲的STS解決方案可以爲您生成令牌。例如，Azure ACS可以通過OAuth2端點生成SWT令牌，並管理與刷新令牌，到期日期和授權授權相關的所有狀態。你在使用它的過程中所節省的成本，你可能會忽略如何與它整合，但它很整潔。