我一直在調查智威湯遜，我對使用它非常感興趣。由於數字簽名和有效負載內容，我喜歡它不需要服務器上的狀態檢查。JSON Web令牌（JWT） - 驗證客戶端
我遇到困難的事情是驗證客戶端。我知道簽名允許服務器說「是的，我發出了這個令牌，它是有效的」，但我並不完全理解服務器如何驗證客戶端是誰說的。
數字簽名在服務器端是有意義的，但客戶端無法簽署任何內容來驗證它是誰，因爲瀏覽器無法保守祕密。這是我無法包裹頭部的一部分。如果瀏覽器無法保密，那麼它如何將數據添加到令牌中（如隨機數或有關所請求資源的信息）以包含在簽名中，類似於oAuth 1.0的工作原理。
這不支持？有沒有其他的方式來驗證瀏覽器是誰說的？如果我的客戶有一個泄漏令牌的安全漏洞會怎麼樣？如果客戶端未通過驗證，任何人都不能使用這些令牌？我不認爲「短期到期」是解決這個問題的好辦法。
有人能幫我把我的頭圍繞JWT的這部分嗎？
驗證客戶端是不是真的可能，因爲它肯定會泄漏一個令牌。令牌過期有助於緩解泄漏的令牌危險時間過長，但正如您所提到的，這不是一種無懈可擊的解決方案。您可以使用請求用戶的當前IP地址作爲簽名密鑰的一部分，以幫助減輕其他地方使用的泄漏令牌的影響。它仍然可以通過XSS在本地使用，但不容易被釣魚者使用。
我的理解是，客戶端不會將信息添加到令牌，它只會將其傳遞到附加信息旁邊。單獨的POST變量 - 一個令牌來「驗證」身份，其他變量定義額外的參數。
要添加到什麼添乙說，我已經使用令牌，其中密鑰後有像這樣的瀏覽器和IP：但是（PHP例）
$secret_key = 'kajsdfkljk' . $_SERVER['REMOTE_ADDR'] . $_SERVER['HTTP_USER_AGENT'];
但這似乎工作， ，如果你從網絡到網絡反彈，那麼你將不得不每次登錄，在這種情況下，你可以使用用戶代理而不是IP。
這裏需要注意的另一件事是，如果有某種泄漏，您可以隨時更改密鑰，其中從服務器發出的所有令牌都不再有效。
另外，如果不使用https連接，令牌可能會非常危險地用於身份驗證。
「另外，如果不使用https連接，令牌可能會非常危險地用於身份驗證」 - 這同樣適用於使用會話公平。如果不使用HTTPS，您無法安全地進行Web身份驗證。 – Delosdos
嗯，我沒有想過使用與客戶端相關的祕密，這是一個好主意。 Oauth 1.0a通過讓「客戶端」（實際上是另一臺服務器）對其整個請求進行簽名來處理此問題。在瀏覽器中沒有辦法做到這一點，但我喜歡使用來自客戶端的動態祕密的想法。 – BeniRose