Keycloak open redirect: wildcard redirect URIs can be exploited to steal tokens

My knee-jerk reaction would be to agree with that. But every single vulnerability I remember being announced for Keycloak was due to some footgun for the authentication protocol.

So, I do assess the risk of a less tested but simpler implementation being way higher than of a well tested complex one.

What leads to the obvious conclusion that it's best to avoid the protocol completely. But if you don't do that, I'd recommend using the mainstream software.

It’s also how it’s hosted: running as an enterprise Java app means you’re getting a high/critical CVE every week for something you probably don’t even use but which is bundled into something like Wildfly. Looking at it currently, I see SnakeYAML, the Apache SSHD, the H2 database, the Infinispan cache, etc. which are just generic Wildfly features and probably not even enabled, but you have to either be very confident about your ability to make that assertion or patching it frequently. This kind of service really needs to be lean and bundling only the dependencies it uses.

I've seen it in multiple installs, and it's used by keycloak's default clients used for the admin app and for the account portals for realms.

It's pretty common in my experience, especially at places that have multiple "apps" behind the same auth.

However, stealing access tokens is only possible with public clients. The open redirect works on both public and confidential clients.

IME Wildcard redirect URLs have become more common in recent years due to the rise of preview environments. If you're deploying a git branch to Vercel, and you now want to log in to <project-name>-git-<branch-name>-<scope-slug>.vercel.app, then you don't want to bother with configuring a different redirect URL for every branch name. Enter the wildcard.

Ideally wildcards are only used in dev/staging environments, but if the system allows for misconfiguration, the system will be misconfigured.

I use it to allow a ?next={url} query parameter in the redirect so I can send users to the page they originally wanted to visit. It becomes more important the faster the access tokens expire because a user can reauth multiple times in a session.

The other way might be to put that URL in redis or something, maybe that's better?

It was published 2024-01-11. The page has been updated to include the publish date. Thanks for the feedback!

> Keycloak was good but has too much legacy for 10+ years.

I got curious, actually seems to check out and explains why it's so well documented (but also complex and oftentimes confusing):

> The first production release of Keycloak was in September 2014, with development having started about a year earlier.

https://en.wikipedia.org/wiki/Keycloak

https://github.com/keycloak/keycloak/releases/tag/1.0.0.Fina...

It's kind of cool to see a project successfully survive for so long.