“日防夜防，家賊難防?！薄按蜩F還需自身硬！”養(yǎng)成鐵的紀律，有助于鑄造堅固的城池。本文從八個方面全面排查你的令牌系統(tǒng)。

你把應用程序代碼推到GitHub了？

OAuth應用程序憑據是否也存儲在倉庫里，特別是客戶端密碼？這可是當今頭號憑據泄漏來源。

如果那些憑證被竊取了，任何人都可以冒充你。如果你察覺憑據可能已被破壞，請立即重新生成。

為了長時間使令牌有效，并直接寫在應用程序中，用于簡化代碼可能很有誘惑力。

但，千萬不要這么做！

token就是門鑰匙！令牌和API密鑰允許任何擁有它們的人訪問資源。

因此，令牌和密碼一樣重要。以同樣的方式重視它們！

OAuth是用于指派對資源的訪問權限的，它不是一個身份驗證協議。

把token看作是門禁卡。你需要驗證自己以獲得密鑰，它無法區(qū)分使用者身份，別人盜用了你的token，就擁有了你的訪問權限。API提供者堅決不能依賴于令牌作為唯一的身份證明。

您確實應該考慮OpenID Connect (OIDC)，這是一種補充規(guī)范，而不是嘗試自己在OAuth上實現身份驗證。OIDC允許用戶與應用程序共享其一部分個人資料，而無需共享其憑證。

JWTs可以用聲明的形式存儲大量信息，如果捕獲了這些信息，就可以輕松地進行解析(除非額外進行了加密)。

如果你使用JWTs來攜帶一些精簡必要的信息，則可以采用不同的方法：

• 在客戶端和后端之間，使用不透明字符串或基本的JWT。
• 在后端，驗證請求，并使用請求參數注入新的JWT。許多API網關也提供了開箱即用的功能。

如果你希望在整個流中使用相同的令牌，同時可能攜帶敏感信息，那就對令牌信息進行加密。也就是說，永遠不要使用JWT來攜帶用戶的憑證。

在服務器端接收JWT時，必須徹底驗證其內容。

特別是，你應該拒絕任何不符合期望的簽名算法，或者使用弱算法，或弱的非對稱/對稱密鑰進行簽名的JWT。

此外，你必須驗證所有payload、過期日期、發(fā)行者和用戶。

瀏覽器本地存儲和會話存儲可以從JavaScript讀取，因此存儲敏感信息(如token)是不安全的。

使用安全cookie、httpOnly標志和CSRF措施來防止令牌被竊取。

這樣做可以限制令牌在運行中被捕獲，避免被寫入代理日志或服務器日志的風險。

你還應該確保在所有涉及發(fā)布和驗證令牌的參與者之間，只使用TLS 1.2/1.3和最安全的密碼套件。

令牌訪問是現代應用程序實現的基礎，但是必須小心處理。

作為后端開發(fā)人員，你必須確保提供適當的授權類型，來獲取令牌，并徹底驗證JWTs。

作為前端開發(fā)人員，也應該謹慎處理JWTs的存儲，并確保應用程序憑據的安全。

Happy coding :)

我是@程序員小助手，持續(xù)分享編程知識，歡迎關注。