我構建了一個應用程式，它根據用戶的選擇使用一些身份提供程式（Auth0、FusionAuth、Azure AD、AWS Cognito）。
我正在使用授權碼流。我面臨存盤令牌的問題。我想只使用身份提供者登錄用戶，我不需要存盤誰是用戶（姓名、電子郵件等）。我只需要對用戶進行身份驗證并確保用戶來自我可以信任的身份提供者。
所以我有4個問題：
- 如果我不考慮使用令牌向身份提供者發出請求，我是否需要存盤令牌。
- 如果沒有轉到 4 問題。如果是，我想知道存盤它們的最佳方式（保存在與 db 的會話中，或者只是將它們作為 Header 的 accessToken 和 cookie 中的 refreshToken 發送）
- 我如何驗證訪問令牌，因為我知道訪問令牌可能是也可能不是 JWT。由于請求的數量，在每個請求上向 IP 發出請求并不是最好的方法。
- 我是否應該使用我自己創建的一對訪問和重繪 令牌來驗證來自前端的請求。
我最近才開始調查 OAuth2，并會感謝任何答案。
截至目前，我有這個流程：
- 從前端(FE) 用戶重定向到身份提供程式(IP) 以登錄。
- IP使用代碼重定向到后端(BE)。
- BE向IP發出請求以獲取令牌。
- BE驗證授權是否有效（通過亂數和狀態）。
- BE通過 httpOnly 安全 cookie 中的 refreshToken 和 query 中的 accessToken將用戶重定向到FE以將其存盤在 localStorage 中。
- 當FE向BE發出請求時，我使用 jwks 驗證 accessToken(JWT)。
uj5u.com熱心網友回復：
在 OAuth 中，您通常不必實作管道來構建自己的令牌存盤。例如，令牌可以存盤在高度加密的僅 HTTP
SameSite=strictcookie 中。但是，您必須保持在 cookie 大小限制內。最好的方法是向 Internet 客戶端發出不透明的令牌（例如 UUID）。Phantom Token Pattern對此有更多資訊。您不應在自己的 API 中使用外部訪問令牌。正如您所發現的，您可能無法驗證它們。此外，它們將沒有有意義的范圍和宣告，您將無法正確授權 API 請求。而是為您自己的 API 發行您自己的令牌。
授權服務器
可以在代碼中發布您自己的令牌，但不建議這樣做。相反，首選選項是使用授權服務器。一種選擇是Curity Identity Server的免費社區版。
該組件將為您處理與身份提供者的連接。然后它將為您頒發令牌，以便您的應用程式和 API 只處理來自單個提供商的令牌。
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/450888.html