在古代戰爭中，出兵的權力往往包含在一件事上——士兵護身符。 它是一種由當局精心製作並分成兩半的令牌，只有當兩半合併進行驗證時，持有者才能獲得指揮軍隊的合法權力。 這份實物檔案保證了軍事行動的安全和命令執行的有效性，是授權和身份驗證的生動體現。
在現代網路世界中，OAuth 2 中體現了類似的授權機制協議中的 0 個令牌。
oauth2.0 代幣就像古代戰場上的護身符，是權力轉移和身份驗證的關鍵工具。 然而，在數字世界中，代幣已經從實體形式演變為虛擬形式，但它所承載的授權使命和背後的安全邏輯不僅與古代代幣一脈相承，而且在技術和規模上也得到了前所未有的擴充套件和深化。
OAuth 2 中的令牌在0協議的各種授權模式中，它被用作授權決策的結果和對服務的後續訪問的身份。 服務端對令牌進行校驗，確保請求者有權執行請求的操作，令牌本身攜帶的資訊可以包括使用者的身份、有效時間、授權範圍等關鍵資料。
之前，我們對 OAuth2 進行了審查0 授權模式執行 **oauth2。0：授權模式已完全解析。
常見的 Token 型別包括訪問令牌、重新整理令牌和 idToken，每種令牌都有其特定的角色、差異和應用場景
訪問令牌用於身份驗證，因為訪問令牌有一定的有效期，過期後不再有效，從而保證系統的安全性。 過期後，客戶端通常需要通過重新整理令牌獲取新的訪問令牌，因此訪問令牌也稱為“短令牌”。
格式要求
AccessToken 沒有從 OAuth 協議級別限制固定格式，它可以是任何格式，但現在 JWT 在一般場景中已經習慣了。 不建議使用者直接解析accesstoken來獲取其中的資訊（因為accesstoken的格式不是JWT的強制要求），需要根據實際的授權服務設計規範來確定。
應用場景
accesstoken 僅用於授權，可用於限制對受保護資源的訪問。 例如使用者介面許可權管理、應用間介面許可權管理，但在標準協議級別，accesstoken 不會用於身份驗證（因為 accesstoken 代表更多的是“許可權範圍”，也就是保護 API）。
發出訪問令牌後，表示的主體可以是“人”或“裝置”。
建議的解決方案中的到期日期配置是什麼？
出於安全原因，accesstoken 的有效期通常很短，但這也需要根據具體情況來決定。 例如：
在不建議使用者參與的場景（如客戶端模式）中，建議稍長一些。
在有使用者參與的場景下：例如，建議授權碼模式和密碼模式稍微短一點，可以依靠refreshtoken實現登入狀態的續訂; 但是，建議配置稍長的配置，如隱式授權模式，因為該模式不支援重新整理令牌，無法實現登入狀態續訂。
如果乙個應用同時以客戶端模式和使用者模式使用，業務端需要考慮實際的業務場景和代幣本身的應用場景。
當使用者通過客戶端應用程式訪問其資源伺服器上的受保護資源時，授權伺服器不僅會向客戶端返回乙個訪問令牌，還會生成乙個重新整理令牌，當“短令牌”訪問令牌到期時，該令牌將傳送到授權伺服器請求新的訪問令牌，而無需使用者登入並再次授權， 從而改善使用者體驗並確保系統的安全性。因此，RefreshToken 也稱為“長令牌”。
格式要求
OAuth 2 中的 RefreshToken0 協議中沒有特定的格式，下面是乙個 refreshtoken 的例子（注意實際的 refreshtoken 通常是加密或編碼的，以確保其安全性，不一定是 JSON 格式）。
1eyjhbgcioijiuzi1niisinr5cci6ikpxvcj9.eyjpc3mioijodhrwczovl2f1dgguawquy29tiiwicmvmcmvzaf90b2tlbl9pzci6ijeymzq1njc4otailcjlehaioje2mdk4ntgwmdasinnjb3blijoib3blbmlkihbyb2zpbgugzw1hawwilcjhdxrob3jpdhkioijbuelfq0xjru5uihbyaxzhdguifq.rkks7lp4lohydy_fvcokcfhs3ftinilwg8yrijeql5o雖然上面的示例看起來像 JWT（JSON Web 令牌），但實際上 RefreshToken 可以是任何格式，例如，它可以只是乙個長字串，也可以是具有多個屬性的自定義序列化物件。
儘管 OAuth 2 未使用 RefreshToken 的特定格式0 規範是嚴格限制的，但為了安全性和可管理性，大多數現代 OAuth 20 實現將選擇使用 JWT 或至少以某種結構化格式儲存 RefreshToken，並在儲存和傳輸過程中保護它。 同時，Refreshtoken 還將實施到期日期控制、黑名單機制等安全策略。
應用場景
當使用者通過身份驗證時，伺服器不僅會為客戶端頒發短期訪問令牌以訪問受保護的資源，還會頒發長期儲存的重新整理令牌。 由於其有效期有限（例如，從幾個小時到幾天不等），訪問令牌在到期後不能使用; 在這種情況下，客戶端可以攜帶 refreshtoken 向認證伺服器請求新的 accesstoken，整個過程不需要使用者再次登入。 這種設計不僅確保了系統的安全性（因為即使訪問令牌被洩露，攻擊者也無法使用它來獲取新的訪問令牌或更新重新整理令牌），並改善了使用者體驗（避免頻繁登入）。 RefreshToken 通常用於支援單點登入 （SSO） 環境和 OAuth 20 等開放授權協議，確保使用者可以在多個連線的應用程式之間保持長期登入狀態，並根據需要動態更新訪問許可權。
建議的解決方案中的到期日期配置是什麼？
RefreshToken 建議方案中的到期日期配置通常很長，以便在 AccessToken 過期後可以長時間保持使用者的登入狀態，而無需重新進行身份驗證。 它的有效期可以是幾天、幾周甚至幾個月，具體取決於系統的安全策略和使用者體驗需求。 此外，系統還應該設計相應的邏輯來撤銷或更新 RefreshToken，並限制單個 RefreshToken 的次數或生命週期，以防止 RefreshToken 使用不當導致的潛在威脅。
在 OAuth 2 中在 0 協議框架下，idToken 是特定於 OpenID Connect （OIDC） 的身份令牌。 [注意：OpenID Connect 基於 OAuth 2 構建。0以上的一組認證層協議，主要用於解決使用者身份識別和認證問題。 】
當使用者通過 OAuth 2 時除了獲取訪問資源所需的 AccessToken 外，OpenID Connect 還允許客戶端請求 IDTOKEN。 客戶端接收並驗證 idtoken 後，可以根據其內容確定使用者的身份，並在必要時將此資訊用於進一步的業務邏輯處理或使用者介面呈現。
IdToken 通常採用 JSON Web 令牌 （JWT） 的格式，它由三部分組成：標頭、有效負載和簽名“建立聯絡。
JWT 標頭包含令牌的元資料資訊，例如加密演算法;
JWT Payload 儲存多個 JSON 編碼的宣告，這些宣告提供有關經過身份驗證的使用者身份的資訊;
JWT 簽名通過對前兩部分進行簽名來確保令牌內容的完整性和可信度。
為了正確處理 idtoken，客戶端需要根據 header 中的說明驗證簽名，並檢查 payload 中每個宣告的有效性，包括但不限於確認 token 沒有過期、受眾匹配自身以及 nonce 值的有效性。
應用場景
idToken 在 OpenID Connect 中的核心應用場景是使用者認證和授權
使用者身份驗證：當使用者登入到啟用了 OpenID Connect 的應用程式時，伺服器將返回乙個 ID 令牌，其中包含使用者的識別符號和其他相關資訊。 應用程式可以通過驗證此令牌來確認使用者的身份。
單點登入 （SSO）：在多個應用程式之間實現單點登入時，使用者只需在乙個位置登入，即可自動登入所有其他應用程式。 在此方案中，每個應用程式都會收到乙個 ID 令牌，其中包含使用者的識別符號和其他相關資訊。
使用者資訊獲取：idtoken除了使用者的身份資訊外，還可以包含使用者的其他資訊，如使用者名稱、郵箱位址、**號碼等。 應用程式可以通過解析 ID 令牌來獲取此資訊，而不必直接從資料庫或其他位置獲取它。
安全傳輸：由於ID令牌是安全令牌，因此可用於保護敏感資訊的安全傳輸。 例如，當應用程式需要將使用者資訊傳送到伺服器時，它可以將該資訊放在 ID 令牌中並將其傳送到伺服器，這樣就不必以明文形式傳輸。
推薦解決方案中的有效期配置是什麼？
idToken 推薦的配置有效期通常較短，以降低安全風險，同時可以與 Refresh Token 一起使用，實現自動續費。 具體有效期根據應用的安全要求和使用者體驗進行調整，旨在保證使用者會話的連續性，同時控制身份憑證濫用的風險。 過期的令牌通過服務端邏輯進行監控和處理，並根據業務規則實施重新整理策略，同時兼顧安全性和便利性。
在當今資訊流量大的網路世界中，OAuth 20的代幣機制無疑是數字社會中至關重要的橋梁。 AccessToken、RefreshToken等Token機制作為堅實的安全屏障，不僅保護了使用者個人資料的私隱，還為服務之間的互動提供了一種安全、靈活、便捷的方式。 有了這個現代版本的護身符，使用者可以精確地管理對其資源的訪問，並確保每次授權都基於證據。