JWT认证机制工作原理解析及相关技术疑问

1. Do users need to send both accessToken and refreshToken with every request? #

Absolutely not—this is a common misconception. In standard JWT authentication flows, you only need to send the accessToken with every regular API request. The refreshToken has one specific job: to request a new accessToken when the current one expires.

Here’s the typical workflow:

• For everyday API calls (like fetching user profiles or submitting data), include the accessToken in the Authorization header using the format Bearer <accessToken>.
• When the server returns a 401 "Unauthorized" response (signaling the accessToken is expired), you then send the refreshToken to a dedicated token-refresh endpoint. Once you get a fresh accessToken, you use that for all subsequent requests.

Sending both tokens on every request defeats their intended separation of roles and raises security risks—refreshTokens have longer lifespans, so exposing them unnecessarily is far more damaging than exposing a short-lived accessToken.

2. If both tokens must be sent together, how should the refreshToken be transmitted (given accessToken is in the HTTP header)? #

First, let’s stress again: this isn’t a recommended practice. But if your use case requires it, the safest way to transmit the refreshToken is via an HTTP-only, secure cookie. Here’s why:

• HTTP-only cookies can’t be accessed by client-side JavaScript, which drastically reduces the risk of XSS attacks stealing the token.
• Secure cookies are only sent over HTTPS, preventing interception in transit.

Avoid putting the refreshToken in the request header (alongside the accessToken) or request body. Storing it in localStorage or sessionStorage is also risky because those storage mechanisms are vulnerable to XSS.

If you absolutely have to include it in the request body, ensure all connections use HTTPS—but this is still less secure than using an HTTP-only cookie.

3. Does the server need to verify the accessToken’s signature first, then check if it’s expired? #

Yes, that’s the correct and secure order of operations, and here’s the reasoning:

1. Verify the signature first: The signature is what ensures the token hasn’t been tampered with or forged. If the signature is invalid, the token is untrustworthy—there’s no point in checking its expiration because it’s already not a legitimate token from your server. Most JWT libraries (like jsonwebtoken for Node.js or PyJWT for Python) automatically reject tokens with invalid signatures before even parsing the token’s claims.
2. Check expiration second: Once the signature is confirmed valid, you then check the exp (expiration time) claim to see if the token is still active. If it’s expired, return a 401 response to prompt the client to use their refreshToken to get a new accessToken.

Skipping the signature check first would create a massive security hole—an attacker could craft a token with a fake exp claim and bypass expiration checks entirely if you don’t verify the signature first.

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