Keycloak持续重定向至登录页问题求助（AWS部署场景）

Let’s break down why your valid JWT is getting redirected to the login page on AWS, even though it works locally. Since your local setup functions correctly, the problem is almost certainly tied to environment-specific configurations—let’s walk through the most likely culprits:

1. Enable Bearer-Only Mode for Your Backend API #

Your current Keycloak initialization doesn’t set bearerOnly: true, which is critical for backend APIs that solely validate JWT tokens (no browser-based login redirect flows). When this flag is missing, the middleware defaults to managing user sessions via cookies, which will redirect to the login page if it can’t find a valid session—even if you send a valid Bearer token in the request header.

Update your init code to include this flag:

public init() {
 if (this.keycloak) {
 console.warn("Trying to init Keycloak again!");
 return this.keycloak;
 } else {
 console.log("Initializing Keycloak...");
 const memoryStore = new session.MemoryStore();
 // @ts-ignore
 this.keycloak = new Keycloak(
   { store: memoryStore, bearerOnly: true }, // Add bearerOnly here
   this.keycloakConfig 
 );
 return this.keycloak;
 }
}

This tells the Keycloak middleware to skip session-based login flows and only validate the Authorization: Bearer <token> header from incoming requests.

2. Verify Token Issuer & Audience Match Your AWS Keycloak Instance #

Even with a valid-looking token, if its iss (issuer) or aud (audience) don’t match what your Express API expects, validation will fail—triggering the unwanted redirect.

• Decode your token using jwt.io and check:
  • iss: Should exactly match https://keycloak.myserver.com/auth/realms/examplerealm (this is your serverUrl + /realms/ + realm from your config)
  • aud: Should include your clientId (ui-client)
• Confirm you’re fetching the token from your AWS Keycloak instance (not your local one)—a local token will have an issuer like http://localhost:8080/auth/realms/examplerealm, which won’t validate against your production setup.

3. Check Proxy/Load Balancer Request Headers #

If your Express API sits behind an AWS ALB, Nginx, or another proxy, ensure it’s correctly passing the Authorization header and informing Express that the original request was sent over HTTPS.

• For AWS ALB:

  • Make sure your target group is configured to pass all request headers (including Authorization).
  • Add this line to your Express app to trust the proxy and use the X-Forwarded-Proto header:

    app.set('trust proxy', true);
    

    This ensures Express recognizes the original request protocol, which is critical for Keycloak’s URL validation logic.

• For Nginx:

  • Add these lines to your server block to preserve the Authorization header and pass the correct protocol:

    proxy_set_header Authorization $http_authorization;
    proxy_set_header X-Forwarded-Proto $scheme;
    

4. Validate SSL Certificate Trust on AWS #

Your Keycloak instance uses a Let’s Encrypt certificate, which is trusted by most modern Node.js versions—but if your AWS Linux server runs an outdated Node.js version (pre-10.x), it may lack the latest root certificates. This causes the Keycloak connector to reject the SSL connection, leading to token validation failures and redirects.

• Check your Node.js version with node -v. If it’s older than 10.x, upgrade to a supported LTS version (16.x or 18.x recommended).
• If upgrading isn’t feasible, you can explicitly trust the Let’s Encrypt root certificate, but upgrading is the cleaner, more secure fix.

5. Confirm Keycloak Client Configuration #

Double-check your ui-client settings in the AWS Keycloak instance:

• Access Type: Ensure it’s set to confidential (you mentioned this, but it’s worth verifying again)
• Valid Redirect URIs: If your frontend calls the API from a different domain, add the frontend’s origin here (use * for testing, but lock it down for production)
• Web Origins: Add your API’s domain here to allow CORS requests with the JWT token (critical if your frontend lives on a separate domain)

Start with enabling bearerOnly: true—that’s the most common fix for API-only setups where you don’t want login redirects. If that doesn’t resolve the issue, work through the other checks one by one.

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