資源服務器應如何驗證授權服務器頒發的 oauth 不記名令牌？

Question

假設我有一個授權服務器 (AS)，它應該產生access_token ，並且我有另一個資源服務器 (RS)，它為我的受保護資源提供服務。

我想知道RS應該如何驗證AS產生的access_token ？

我的困惑是，AS 在簽署access_token時應該有它的秘密方式，這並不意味着其他任何人都不會共享或知道，在這種情況下，RS 不應該知道 AS 是如何生成這個access_token的。

在這種情況下，RS 應該如何驗證收到的令牌並確保令牌來自已識別的 AS？ 相反，驗證 RS 上收到的令牌不應該是 AS 的責任嗎？ 但如果是這樣的話，它不會面臨任何性能瓶頸，因為對 RS 的每個 API 調用都需要額外的跳轉到 AS 來驗證令牌？

Answer 1

通常，由 AS 發布的令牌使用私鑰進行簽名。 AS 還發布任何人都可以下載的公鑰。 例如，谷歌在這里發布了它的公開簽名密鑰。

稍后，當 RS 收到 access-token 時，它會從 AS 下載公鑰並驗證 token 的簽名。 如果匹配其接受。 除了驗證簽名之外，它還檢查令牌內的其他聲明，例如 aud-claim（受眾），如果他的令牌實際上是供 RS 使用的，那么它是否可以使用。

或者，RS 可以使用共享密鑰來驗證令牌。 在這種情況下，RS 是一個受信任的（機密客戶端），我們知道它可以保守秘密，並且可以安全地與我們信任的服務共享秘密。

Answer 2

正如您所說的 Isaac，有些人（包括我自己）更喜歡將令牌驗證從 API 外部化，並要求授權服務器來完成這項工作。 我認為這是最干凈的選擇，因為：

• 它將您所有 API 的安全代碼外部化
• 可以在不影響 API 的情況下更改令牌簽名密鑰或算法

這可以通過自省來實現，這通常還涉及緩存結果（聲明）。 這就是很多 API 網關解決方案的工作原理，但您也可以很容易地自己編寫代碼。

我的一些相關資源：

• API 授權博文
• 自省代碼

Tore 描述的技術也是完全有效的，如果授權服務器不支持自省，則需要此技術。