Hello everyone! I'm trying to develop a very simple filter for an application to exchange the user token with keycloak for another one with different scopes and I'm in trouble with the issuer not matching. Both the filter and keycloak are deployed in docker containers and connect directly to each other. The user authenticating into this application does it through a public website, e.g. https://sample.com so the issuer in the token will look something like https://sample.com/auth/realm or similar given the current implementation. The filter exchanging the token connects to keycloak through http, e.g. http://my-keycloak the issuer would normally look like http://my-keycloak/auth/realm, but because we are configuring the fixed hostname provider to be sample.com it actually looks like http://sample.com/auth/realm <https://sample.com/auth/realm>;, so it's pretty close but it's http instead of https because the hostname SPI introduced in KEYCLOAK-7967 <https://issues.jboss.org/browse/KEYCLOAK-7967> doesn't support a fixed schema (as far as I could tell at least by looking at the PR and configs). And because that's being used to validate the token, and there's no way I'm aware of setting the schema I haven't been able to get it running properly. Is there any known solution to this limitation? My take is that schema should be supported by the fixed hostname provider, otherwise I think it misses the point of supporting a "backchannel URL back to the adapters to allow adapters to use internal IP address when communicating with Keycloak" On top of that, I believe there's a confusion on what the issuer is; As per RFC-7519:4.1.1 <https://tools.ietf.org/html/rfc7519#section-4> The "iss" (issuer) claim identifies the principal that issued the JWT. The processing of this claim is generally application specific. The "iss" value is a case-sensitive string containing a StringOrURI value. Use of this claim is OPTIONAL. i.e. not a URL and certainly not necessarily linked to the URL of the issuing system, it's just a URI value defined arbitrarily. I believe that this concept is more closely related to realm application clients rather than to the entire keycloak server; i.e. issuer/accepted issuers could be defined per client. Because of this I've taken the liberty to raise KEYCLOAK-8310 <https://issues.jboss.org/browse/KEYCLOAK-8310> Still, is there any known/recommended way to workaround this issue? Thanks for your time, Fernando.