JWT身份认证机制解析：如何验证用户真实身份？

Great question—you’re hitting on a key limitation of JWTs that a lot of folks overlook at first! Let’s break this down clearly.

First, let’s recap what a valid JWT actually proves, as you noted:

• The token was signed by your server (so it hasn’t been tampered with)
• When the token was issued, the user provided valid credentials (they were who they claimed to be at that moment)

What it doesn’t prove is that the person using the token right now is the same person who originally logged in. That’s exactly the gap you’re noticing—stealing a JWT (from localStorage via XSS, for example) lets an attacker impersonate the user until the token expires.

So how do you fix this? Here’s what you’re missing:

1. Never trust user-provided userid values #

Your JWT payload should already include the user’s authentic identity (use the standard sub field for this, which stands for "subject"). When processing a request:

• Validate the JWT’s signature first
• Extract the user ID directly from the JWT payload, not from the request body/params

This way, even if an attacker steals John’s token, they can’t claim to be Alice by sending a different userid—modifying the payload would break the token’s signature, making it invalid. This eliminates the problem of users "claiming" an identity separate from the token.

2. Shorten JWT lifespan + use refresh tokens #

Set your access JWTs to expire very quickly (15 minutes is a common choice). Then issue a longer-lived refresh token (stored in an HttpOnly, Secure cookie) that lets users request new access tokens without re-logging in.

This limits the window of opportunity for a stolen token to be used. If a token is stolen, it’ll only work until it expires, and the refresh token is harder to steal (since HttpOnly cookies can’t be accessed via JavaScript, mitigating XSS risks). You can also invalidate refresh tokens server-side if a user logs out or reports a breach.

3. IP binding is usually a bad idea #

While binding a JWT to an IP might seem like a fix, most users have dynamic IPs (mobile networks, home ISPs that rotate addresses). This would lead to legitimate users being logged out unexpectedly, hurting user experience. Only consider this for highly restricted internal systems where IPs are static.

4. Add extra layers of security for sensitive actions #

For high-risk operations (changing passwords, making payments, updating personal info), require secondary verification like:

• SMS/email codes
• Multi-factor authentication (MFA)
• Biometric verification

This ensures that even if a token is stolen, the attacker can’t perform critical actions without additional proof of identity.

5. Store JWTs securely #

Avoid storing JWTs in localStorage—instead, use HttpOnly, Secure cookies. This prevents XSS attacks from stealing the token in the first place. You’ll also need to implement CSRF protection since cookies are automatically sent with requests.

To sum up: #

JWT doesn’t directly verify that the current user is the original owner—but when used correctly, it lets you:

1. Confirm the token is legitimate
2. Get the user’s identity from the token itself (no need for them to claim it)
3. Minimize the risk of stolen tokens being useful for long

Combine these practices, and you’ll have a robust authentication flow that addresses the gap you identified.

内容的提问来源于stack exchange，提问作者Sandeep Gupta