OAuth2服务器Http重定向表单：URL哈希添加及隐式流相关疑问

Let’s break down your two key questions clearly—this part of OAuth can feel opaque at first, so I’ll keep things practical.

How is the URL hash added to the redirect URI? #

Absolutely, the OAuth 2.0 authorization server is the one that directly appends the hash fragment (containing the access_token, token_type, and related parameters) to your pre-registered redirect URI. It then sets this full, hash-included URL as the value of the Location header in its 302 response.

For example, if your registered redirect URI is http://www.abc.de/de, the server will craft a Location header that looks like this:

Location: http://www.abc.de/de#access_token=your_unique_token&token_type=Bearer&expires_in=3600

When the browser gets this 302 response, it redirects to the complete URL including the hash. A critical detail here: browsers never send the hash portion to the backend server—it stays strictly client-side, which is why the implicit flow uses this method to deliver tokens directly to frontend apps without exposing them to server logs or intermediate parties.

How to confirm the returned access_token is trustworthy? #

Verifying token validity is non-negotiable for app security. Here are the core steps to do it right:

• Validate the signature (for JWT tokens): Most implicit flow tokens are JSON Web Tokens (JWTs). You’ll need to fetch the authorization server’s public key (usually from a dedicated JWKS endpoint) and use it to confirm the token’s signature hasn’t been tampered with. A valid signature proves the token was issued by your trusted OAuth server, not a malicious actor.
• Inspect token claims: Dig into the JWT’s payload to check:
  • iss (issuer): Exact match with your OAuth server’s official URL.
  • aud (audience): Matches your app’s registered client ID.
  • exp (expiration time): Is a timestamp that’s still in the future (so the token isn’t expired).
  • Any custom claims relevant to your use case (like sub for user ID) align with what you expect.
• Enforce HTTPS for the entire flow: HTTPS encrypts all communication between the browser and OAuth server, preventing attackers from intercepting or modifying the 302 response’s Location header—and thus tampering with the token in the hash.
• Confirm redirect URI matches registration: The OAuth server will only send tokens to redirect URIs you’ve pre-registered. If the URI used in the flow doesn’t exactly match the one on file, the server won’t issue a token—this stops tokens from being sent to malicious sites.

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