KeyCloak 9 upgrade broke relative redirect-URIs

Getting advice
1

We recently upgraded our KeyCloak instances to version 9 from 7, but in the upgrade, some of our redirect URIs embedded in KeyCloak calls started breaking. Specifically, if the URI was a relative path (ie: ‘/our-app/’), KeyCloak would say it’s an invalid redirect-URI when it tried to redirect. In order to fix the issue, the redirect-URI had to be altered to be fully-qualified (ie: ‘https://ourserver/our-app/’). This is the client config for the specific client with the issue in our realm:

{
  "clientId": "app-portal",
  "enabled": true,
  "name": "App Portal",
  "publicClient": true,
  "redirectUris": ["/our-app", "/our-app/*"],
  "protocolMappers": [
    {
      "name": "expose-user-id-attribute",
      "protocol": "openid-connect",
      "protocolMapper": "oidc-usermodel-attribute-mapper",
      "consentRequired": false,
      "config": {
        "userinfo.token.claim": "true",
        "user.attribute": "userId",
        "id.token.claim": "true",
        "access.token.claim": "true",
        "claim.name": "attributes.userId",
        "jsonType.label": "String"
      }
    },
    {
      "name": "expose-group-id-attribute",
      "protocol": "openid-connect",
      "protocolMapper": "oidc-usermodel-attribute-mapper",
      "consentRequired": false,
      "config": {
        "userinfo.token.claim": "true",
        "user.attribute": "groupId",
        "id.token.claim": "true",
        "access.token.claim": "true",
        "claim.name": "attributes.groupId",
        "jsonType.label": "String"
      }
    }
  ]
},

Any suggestions about what might be going wrong would be helpful. The only change made to the KeyCloak config on upgrade was changing the KeyCloak docker container version to 9.0.3, so whatever settings we had worked for 7, but don’t anymore with 9.

NOTE: The folks who set up our KeyCloak container originally are no longer with the company, so it’s possible that things were never configured correctly, but KeyCloak 7 didn’t care.

2

Tooltip for redirect URI field (it is from v12, but it can be the same as v9, see the bold):

Valid URI pattern a browser can redirect to after a successful login or logout. Simple wildcards are allowed such as 'http://example.com/'. Relative path can be specified too such as /my/relative/path/. Relative paths are relative to the client root URL, or if none is specified the auth server root URL is used. For SAML, you must set valid URI patterns if you are relying on the consumer service URL embedded with the login request.

So I would try to configure client root URL properly first.

3

I’ll give that a try. Only issue I see for us is we currently use the same KeyCloak instance for dev and local apps. We’d have to create a separate instance for localhost development (Or reroute our dev server name locally to localhost, but that would be annoying if we were switching between local and dev instances frequently).

4

There is nothing stopping you to configure all stages absolute redirect URLs (localhost included) for one client (absolute = you don’t need to configure root url):

image
image934×243 14.6 KB

It will be only good practice to have dedicated client for each stage.