微服務認證體系結構與passport.js

Question

我正在寫一個玩具應用程序，用於在nodejs（expressjs）上實踐微服務和認證。

我有一個反應客戶端，身份驗證服務和其他服務（他們只是迴應「嗨」到目前爲止）。

• 客戶端將託管在CDN中。
• 身份驗證服務在端口5000上偵聽（例如）
• 其餘服務在端口6000-6100上偵聽。
• 我有一個redis數據庫來存儲會話信息（Twitter提供的oauth令牌）。
• 存儲應用程序信息的mongodb（與此問題無關）。

這個想法是，未經身份驗證的客戶端通過單擊Twitter按鈕（SSO）進入身份驗證服務。然後，auth服務獲取生成的twitter宣誓令牌，並在redis存儲中設置此令牌。然後，令牌可以被其他服務訪問，以便通過檢查它是否已存在於redis存儲中來了解請求是否已通過身份驗證（如果用戶刪除了其帳戶，它也將從redis存儲中刪除） 。 一旦通過身份驗證，我就會從客戶端向服務器發送Twitter令牌。

我發現這種方法非常簡單（他人用於身份驗證的nginx的代理，但我看不出有什麼理由認爲，除非這些服務在不同的域託管，但我不明白它非常好）所以我擔心我錯過了關於安全的一些事情。

問題：

1. 是這種做法是否正確？
2. 共享Twitter令牌是否安全？（我認爲是）？
3. 是否有任何安全問題，我沒有注意到這裏？

Answer 1

使用這種方法，你將不得不驗證所有服務中的令牌，如果你沒有問題，那麼你可能沒問題。

Twitter的訪問令牌可有到期時間，這將使它必須使用刷新令牌來獲取從身份驗證服務新的訪問令牌：

• 當訪問令牌過期，你會返回一個401從服務X到客戶端，您正在嘗試與之交談。
• 客戶將不得不調用驗證服務提供一個刷新令牌，獲得新的訪問令牌
  • Finaly客戶端將再次與這個新的訪問令牌擊中X服務，有它驗證，並得到預期的服務X的迴應。

在我recent assignment我寫了一個微服務，代理所有的令牌，使用這種方法我的代理從身份驗證到角色處理一切和發送401的過期令牌和撤銷刷新令牌等等。我覺得這給了我更多關注的分離。

重要提示：在上面我的代理刷新令牌的情況不僅會遇到負載無效/過期的accessToken，而在方案中的任何服務可以用無效的令牌來達到...

另一種方法是可以讓Service-A和Service-B調用auth服務來驗證令牌，但這會推斷服務之間的流量更多，因爲每個帶令牌的HTTP請求都必須經過驗證。在這種情況下，一個無效的令牌請求會到達您的服務X並因此推斷它的一些負載...