Hi, we're having a scenario with a Keycloak (OIDC) protected classic web application (no SPA) which has the restriction that it is not allowed to do any internet requests from its server within the DMZ it is located. Due to this restriction it cannot execute any back-channel requests (e.g. /token, /userinfo) to Keycloak because the configured "auth-server-url" is the front-end URL which is only visible through internet and actually points to Firewall/Loadbalancer component. Now the question: What do you think about an enhancement request for Keycloak (server and OIDC adapter) to allow different URLs for front-end (browser redirect) and back-channel URLs? That would imply several changes: 1. The server side endpoint implementations (UserInfoEndpoint, TokenIntrospectionEndpoint) are using TokenVerifier which by default checks the token issuer. This check will fail because the realmUrl of the back-channel request will be unequal to the token's issuer URL, which comes from the session created at login with the front-end URL. There are several variants to handle this: a) There is already a boolean varibale "checkRealmUrl" in TokenVerifier to disable this check, but no way to set it to false. It might be an option to support a switch per client to disable/enable this check. b) Instead of deriving the issuer name from the current request URL it might be possible to (optionally) provide an explicit issuer name field per realm. That would allow setting issuer names that are completely independent of any network infrastructure. c) When issuing a token through TokenEndpoint, set the issuer to the current /token request URI rather than using the one from the associated session. see TokenManager.initToken(): token.issuer(clientSession.getNote(OIDCLoginProtocol.ISSUER)); 2. The OIDC adapters must support a new (optional) configuration parameter (e.g. "auth-server-redirect-url") to allow setting a separate front-end URL. Do you see any security issue with such an enhancement? Cheers, Manfred