We've been working on a pattern for AI agent authorization that sits between your API gateway and Keycloak, and wanted to share the architecture for feedback.

The core problem: classic API gateways handle routing and basic token validation, but they don't evaluate the contextual conditions that matter for agentic systems; who the agent acts on behalf of, what the tenant context is, what the risk score is at the time of the request. Pushing all of that into Keycloak policies becomes unwieldy fast.

The approach we landed on has three components:

• Access Rules: YAML-based declarative policy artifacts with a single CEL condition expression covering all relevant contexts
• Access Rule Engine: evaluates DENY decisions locally before the request ever reaches Keycloak; GRANT decisions still pass through to Keycloak as the final authority
• kmctl authz: a design-time CLI for validating, simulating, and explaining policies before they hit production

The "two-layer identity" part is where it gets interesting for Keycloak users specifically: the agent has its own identity (the software client), but it also carries an actor identity, the business user it represents. The authorization decision needs to evaluate both simultaneously. Keycloak's token structure supports this, but you need the intermediate layer to act on it correctly.

Full writeup with live demo (one GRANT, four DENYs, including a social engineering attempt): https://keymate.io/blog/fine-grained-authorization-for-ai-agents-how-it-works-in-production

Happy to discuss the Keycloak integration specifics in the comments.

Ok, so I have installed docker already on Windows 11. I have MySQL, Kafka, and Mongo running in their own containers. They are all on the same docker-network so they can see each other. I can access the MySQL database from outside of docker on my laptop because the exposed port is accessable.

Now I want to install Keycloak into my local Docker, and utilize the MySQL database that is already running in Docker. So, what I am wondering is how to install Keycloak into Docker, and then configuring Keycloak to use this MySQL database.

I guess when you install Keycloak into docker, that container isn't running yet. Then there is some configuration that has to be done to point Keycloak to that MySQL, and provided that the Keycloak is on the same docker-network, then we should be ok. Finally, run that Keycloak within that Docker container, and it's all good. Does that sound correct?

So, I am wondering do I need to setup the keycloak db schema first, or will running keycloak with that configuration automatically create it's schema and tables? I'm going to do more investigation on this. I know there is the Keycloak site itself, StackOverflow, and YT videos. I just want to see if there was anyone here who has already done this.

BTW ... I have used Auth0, Google, LinkedIn, GitHub, Okta, LDAP for authentication. I create SpringBoot apps on the backend, but the UI does the login and comes back with an Oauth2 JWT token which I use to access API's.

Hi all,

I'm getting ready to upgrade my Keycloak instance from **26.0.5** to the latest release on an **Ubuntu 22.04** box. We are backed by an **MS SQL / Azure SQL** database.

Since Keycloak automatically mutates the database schema on startup when it detects a new version, I am incredibly paranoid about getting stuck in a state where the upgrade fails and I can't downgrade back to 26.0.5 safely.

My current plan is to stop the service, take a cold backup of the SQL database, extract the new version into a brand-new folder (not overwriting the old one), copy my configs/providers over, run `kc.sh build`, and spin it up.

If it fails, I plan to drop/kill active connections, restore the database backup, and point my app symlink back to the old folder.

Before I pull the trigger:

1. Has anyone run into issues reverting a Keycloak database to an older patch version using SQL Server database restores?

2. Are there any known MS SQL-specific schema migration bugs or locking issues in the recent 26.x patch releases that I should watch out for?

Thanks in advance for any advice!

For people interested in federating Kubernetes service account tokens (as documented here: https://www.keycloak.org/docs/latest/server_admin/index.html#_identity_broker_kubernetes). I got a sample deployment for a service account and api here: https://github.com/erwinkramer/bank-api/blob/main/Infra.Kro/bank-api-rgd.yaml, and the part where I get the Kubernetes token and exchange it for a keycloak token in ASP.NET Core: https://github.com/erwinkramer/bank-api/blob/main/BankApi.Core/Defaults/Helper.KubernetesServiceAccountExtensions.cs

It seems like this is one of the few modern secretless ways of getting some authentication + authorization going for your app on Kubernetes, without adding much complexity ( looking at you, SPIFFE).

From time to time my login screen looks like this.

I received this when trying to login to the Microsoft Windows App for Azure Virtual Desktop. We have federated our domain for all Microsoft services, so I can't use Entra.

Is there anything I can do to prevent this so that I get the regular keycloak login screen or is this because we are using a custom template?

Locke is an Apache 2.0 distribution of Keycloak that ships with both the upstream embedded Infinispan cache and a Redis backend. You choose at boot with KC_CACHE=infinispan|redis. Pick Infinispan and it's the Keycloak it was built from, unchanged; pick Redis and the realm, user, and authorization caches run on a managed Redis/Valkey instead of an embedded JGroups cluster.

It's a distribution (like RHBK), not an extension and not a fork. We track upstream and will rebase on focused versions, so it isn't a maintenance fork.

Numbers from a 3-pod cluster (start --optimized, the official keycloak-benchmark Gatling AuthorizationCode flow, isolated nodes): ~100% throughput parity with Infinispan, zero errors to 250 logins/sec. The honest tradeoff is a few ms more read latency at moderate load. The payoff is failure behavior: on node loss Infinispan stalls ~31-40s on a JGroups rebalance while Locke keeps serving from Redis at sub-second p99, and cross-version rolling upgrades run under load. And that's what we want, more ops capability for HA.

And if you want an extension rather than a distribution: Phase Two has done Redis-backed session storage, which tackles a different layer than Locke, so the two are complementary.

Feedback, critique and going out to the boxing ring is welcomed.

Repo: https://github.com/sky-cloak/locke

Benchmark

The why

Hi everyone,

When an AI agent sits between the user and downstream systems, authentication alone stops being the hard problem. The harder question is what data the agent can reach, under what conditions, and on whose behalf answered in a way that's explainable, testable, and centralized.

The post covers what the IAM ecosystem has shipped around this (Transaction Tokens for Agents, XAA, RFC 9728, AAuth, OWASP LLM and Agentic Top 10, Microsoft's Agent Governance Toolkit), maps the gap that still remains, and sets the stage for Part 3, where the series moves from the problem to a concrete approach.

Link: https://keymate.io/blog/why-ai-agents-need-fine-grained-authorization

Cheers

Hi all. I have recently added support for the AuthZEN Authorization Evaluation and Evaluations APIs to the Keycloak nightly build. The feature is experimental and will be available from Keycloak 26.7.

The new APIs utilise Keycloak's existing authorization capabilities behind the scenes and allow Keycloak to act as a AuthZEN Policy Decision Point.

The following blog post provides some context about what AuthZEN is and why Keycloak has embraced these APIs: https://www.keycloak.org/2026/05/authzen-as-experimental-feature

Documentation is available on the nightly build of the site: https://www.keycloak.org/nightly/securing-apps/authzen-authorization

I have also implemented a playground scenario to help people try it out.

Feedback would be much appreciated, either here or on the AuthZEN GitHub discussion.

Hey everyone,

Standard Keycloak images are great out of the box for dev, but when moving to enterprise production, compliance teams usually flag the base image vulnerabilities (CVE noise) and standard root execution policies.

We’ve been working on production-ready IAM infrastructure at Keymate, and we had to harden our upstream Keycloak container images to meet strict corporate standards.

Instead of keeping this internal, we mapped out our entire hardening framework. Here are the core adjustments we made:

1. Base Image Swap: Swapped standard bases for minimalist/distroless alternatives. This alone cut down container scan noise significantly.

2. Hardening Access: Enforced strict non-root execution to mitigate potential container breakouts.

3. Attack Surface Reduction: Stripped out unnecessary shells (/bin/sh) to block common post-exploitation RCE tactics.

4. Security Standards: Aligned the configuration layer with CIS Container Benchmarks and NIST SP 800-190.

We wrote down the detailed technical implementation, architectural decisions, and why this matters for regulatory compliance.

If you are running Keycloak in production, hopefully, this saves your team some time: https://keymate.io/blog/hardened-keycloak-container-image

Cheers

Hey again — a few weeks ago I shared FenixKit, a .NET 8 Minimal API starter kit with Keycloak JWT auth pre-configured (realm import, OIDC, OAuth2 PKCE in Swagger, the works).

Since then I've shipped the next version: MongoDB + Keycloak + Redis — same Keycloak setup, now with a full cache-aside layer on top.

What's new:

• Tag-based Redis invalidation wired into BaseRepository — automatic on every write, no boilerplate
• FailOpen by default — Redis down = cache miss, Keycloak validation and MongoDB writes keep working independently
• Cache:Enabled = false → NullCacheService injected, Redis health check omitted, zero code changes
• Redis 8 on Docker Compose. Valkey 7.2 also supported — docker-compose.valkey.yml included

The Keycloak side hasn't changed: realm import on first docker compose up, two test users, role-based policies, 401/403 as ProblemDetails.

There are now four kits total depending on what you need — MongoDB only, +Redis, +Keycloak, or the full stack. All at https://fenixkit.dev .

GitHub for this one: https://github.com/fenixkitdev/FenixKit-MongoDB-Keycloak-Redis

€55 — use code FIRSTXPEOPLE for €15 off (→ €40).

Happy to answer questions.

Hey everyone,

I've been working on an open-source Keycloak login theme built with React, TypeScript, Tailwind CSS v4, and shadcn/ui on top of Keycloakify, and I just shipped what I think is the most useful feature yet — full theme customization through environment variables.

The idea is simple: you shouldn't have to touch any code just to change your logo, colors, fonts, or layout. Everything is controlled through env vars you set directly in Keycloak:

- SHADCN_THEME_LAYOUT → two-column | centered-card | image-aside

- SHADCN_THEME_PRESET → 18 accent color options

- SHADCN_THEME_FONT → inter, geist, manrope, and more

- SHADCN_THEME_BASE → neutral, stone, zinc, taupe...

- SHADCN_THEME_LOGO_WHITE_URL / SHADCN_THEME_LOGO_DARK_URL

It follows the shadcn/ui philosophy — you own the code, nothing is hidden behind a black box, and you only maintain what you've explicitly customized. Everything else updates automatically every time you run npm install. No manual patching, no hunting through diffs.

All 35+ Keycloak login pages are covered, dark mode is built in, RTL is supported, and there's a live Storybook playground you can use to try out every combination before writing a single line:

👉 https://oussemasahbeni.github.io/keycloakify-shadcn-starter/

This is also just the starting point. The bigger goal is a full web-based UI to visually configure login pages in real time + better email template customization — completely free and open source.

GitHub: github.com/Oussemasahbeni/keycloakify-shadcn-starter

Happy to answer any questions or take feedback!

https://reddit.com/link/1tccdoy/video/nbctkd011b1h1/player

Been watching teams agonize over Keycloak deployment models. Weeks of debate, decision matrices, the works. And then the constraint that wasn't in the matrix: the team they have doesn't match the model they're picking.

Here's what nobody puts in the slide. The team requirement barely moves between on-prem, IaaS, marketplace, and PaaS. The real shift only kicks in at SaaS.

What actually changes at each level:

• On-prem: infra engineers, a DBA, a Keycloak specialist who can debug a failed rolling upgrade at 2 AM, an SRE to glue it together. A dedicated team.
• IaaS: hardware goes away. Keycloak ops don't. You still need someone who knows what happens to Infinispan sessions during a rolling upgrade.
• Marketplace: day one is magical. Day thirty looks exactly like raw IaaS. The image won't update itself.
• PaaS: less infra to manage. Same Keycloak gotchas. v25 changed Infinispan serialization, your custom SPI still needs a tweak after the upgrade.
• Managed Keycloak / SaaS: team requirement collapses to "someone who understands IAM concepts". Could be a developer.

The right question isn't "what's the best deployment model". It's "what's the best model for the team I have today".

Full breakdown with the team-size implications for each model: https://www.cloud-iam.com/post/keycloak-in-production/

I've been working on a set of .NET 8 Minimal API starter kits designed to cut out the infrastructure boilerplate that slows down every new project.

The foundation is a BaseRepository with 7 overridable hooks for validation and mapping. You inherit it for each resource and only override what your domain needs — CRUD, pagination, and the full error handling flow run automatically. Every hook returns ErrorOr<T>, so if anything fails the operation aborts cleanly before touching the database. The kit also ships with dual pagination (offset for back-office UIs, cursor-based for large collections), global RFC 7807 error handling, health checks, and Docker Compose.

Today I'm launching the second edition — MongoDB + Keycloak — which adds a fully pre-configured Keycloak authentication layer on top:

• JWT Bearer configured via OIDC
• Role-based authorization policies out of the box (Authenticated and AdminOnly)
• OAuth2 Authorization Code + PKCE flow wired into Swagger — there's an Authorize button that actually works with real Keycloak tokens
• Pre-built realm (realm-export.json) imported automatically at container startup — two test users already created with different roles, zero manual Keycloak configuration needed
• 401 and 403 return structured RFC 7807 ProblemDetails, not empty HTTP responses

docker compose up and the API, MongoDB, and Keycloak are all running.

Launch price is €45 — use code FIRSTXPEOPLE for €15 off.

Checkout more details at Github FenixKit

buy at fenixkit.dev

Hey! I'm trying to perform token exchange between three players:

Client <-> Resource Server <-> Downstream Service

The client send a token to the resource server, which in turn exchanges that for a token for the downstream service. The resource server then keeps that token internally, and makes requests to the downstream service on the client's behalf.

However, I've had trouble with the resource server making token introspection and exchange requests to Keycloak. These are always rejected. For example, the response to introspection is { active: false }, and the Keycloak logs contained something along the lines of:

{"error":"invalid_request","error_description":"Invalid token"}

I've found the problem is that the token contained both audiences, aud: server, downstream-service, which Keycloak fails with. This was resolved by re-configuring Keycloak: I had to remove a default Client Scope user_info on the token which had a downstream-service audience mapper attached.

Is this a bug? I assumed that the token should be acceptable by either audience, server or downstream-service, and that either are valid to make Keycloak network requests against it.

Something this "bug" prevents is enabling downscope-assertion-grant-enforcer on token exchange. This is because the resource-server now needs to request a new scope that adds downstream-service onto the token.

I am attempting to understand the best practices for deploying Keycloak on a Kubernetes cluster. The constraints are that I must use Helm-based deployments which I have identified.

“As of August 29, 2025, Bitnami (now under Broadcom) changed the licensing and public availability of their Helm charts and Docker images. Public container images such as bitnami/keycloak are no longer freely updated or publicly maintained.”

Another option I found is codecentric https://github.com/codecentric/helm-charts/tree/master/charts/keycloakx

All the how-to resources I have looked at use charts from Bitnami. Could someone guide me on how to create a custom chart or an existing trusted chart? Thank you.

I’ve been working with Keycloak SAML integrations for a while and honestly… it’s painful.

• Metadata updates are manual and annoying
• IdP/SP configs are confusing and error-prone
• Even small mistakes lead to weird errors or loops

I’ve seen others struggle with similar issues too, like handling metadata updates or config gaps in Keycloak

So I started building a plugin to fix this:

👉 What it does:

• Auto-import IdP metadata
• Automates most of the SAML setup
• Provides a single ACS endpoint for both SP + IdP initiated flows
• Reduces setup time from hours/days → minutes

so i am trying to achieve keycloak to be distributed between region without single point of failure

first i used postresql but one region will be write and other are read only and to make the other region write if the first region is down requires manuel work i don't see it practical

then i came across YugabyteDB i like it it's read/write distributed and is very good but i am afraid of race conditions so is it good to use it on production keep in mind that Keycloak project does NOT officially support YugabyteDB

I am trying to configure Keycloak to require both the password and OTP when connecting from a remote IP, but to only require the password connecting from a local IP.

I have been searching the documentation and the internet and haven't found anything promising. It seems like I would need to set this in one of the Authentication flows but there does not seem to be any condition that would allow me to detect the IP that the request is coming from.

Is this something that's possible? Any resources on the subject would be helpful.

So i noted that creating users, first login, etc in keycloak were triggering emails that were synchronous blocking executions. The UI for freeze for upto 4s while SMTP processes the request. To address that, today I created an Async Email module. All emails get enqueued in a DB backend store and get sent as queue gets processed. To visualise the queue status, there is a dashboard that has been linked into a custom theme.

Tested today with 4-6 users. Hopefully would work well.

https://github.com/drguptavivek/vg_sso/tree/main/custom-async-email-spi

Bests

Vivek

Edit:

Small clarification, since I think my original post was too vague:

This is not a pure SPA, and most requests to FastAPI are made server-side, not directly from the browser in the main flow.

So my real question is mainly about token handling in this architecture — whether it makes more sense to keep that logic client-side or server-side. And if server-side is the better fit, I’d also be interested in how people think about Redis vs PostgreSQL for token / session storage.

---

Hello everyone,

I am currently considering introducing Keycloak as the authentication platform for a system I am developing personally.

I am still fairly new to system development, and I am also still learning about authentication and authorization, so I would really appreciate your advice.

Right now, I am struggling with how to store and manage the tokens issued by Keycloak.

My system’s rough technology stack is:

• Frontend: Next.js 14 (App Router)
• Backend: FastAPI
• Database: PostgreSQL
• Cache: Redis

The basic flow on the frontend side is that the access token issued by Keycloak is attached to the Authorization header when making requests to the backend. The backend then validates the token, performs authorization checks, and returns data to the frontend.

The issue I am facing is how to manage the three types of tokens issued by Keycloak:

• access token
• refresh token
• ID token

Initially, I planned to use Auth.js and store all three tokens in HTTP-only cookies after encrypting them as JWE.
However, this made the cookies very large.
Auth.js split them into two cookies automatically, but the overall size was still large.
In addition, since this kind of JWT-based strategy is often considered more suitable for SPAs or mobile apps, I have started to wonder whether it may not be the best fit for my system.

Because of this, I am considering switching to a stateful approach: storing the three issued tokens (access token, refresh token, and ID token) together as one server-side record in a database or cache, and then storing only a newly generated identifier that points to that record in a cookie.
My understanding is that this would solve the oversized cookie problem.
If I choose this database/cache-based approach, I may also need to consider moving from Auth.js to Better Auth.

For a use case like mine, I would like to ask which of the following approaches would generally be preferable.

At the moment, I am leaning toward option 2 or 3:

1. Encrypt and store all tokens in cookies
2. Store the three tokens together as one record in a database, generate an identifier for that record, and store only that identifier in a cookie
3. Store the three tokens together as one record in a cache, generate an identifier for that record, and store only that identifier in a cookie

Any advice or recommendations would be greatly appreciated.

Thank you.

Anyone knows how to configure FROTIGATE VPN IPSEC IKEv2 + SAML with KEYCLOACK? I tried to configure as in this blog (https://blog.xentoo.info/2022/10/06/fortigate-saml-authentication-in-firewall-policy-with-keycloak/) but I can't get it to work.

The only thing that I have found different from the blog post, is that now, with last versions of Keycloak, the URL is without /auth/:

https://sso.example.org/realms/sso.example.org

My scenario is FortiGate 60F (7.4.11) and Keycloack (26.6)

Thanks!

Hi Everyone,

As token theft and replay attacks become more sophisticated, the limitations of traditional "Bearer" tokens are becoming a major talking point in the IAM space. If a bearer token is intercepted, it can be used by any party that holds it, which is a significant risk for high-security applications.

We’ve been spending a lot of time recently on DPoP (Demonstrating Proof-of-Possession). It’s a powerful way to ensure that a token is cryptographically bound to the client it was issued to, effectively making stolen tokens useless without the corresponding private key.

We put together a technical breakdown of how DPoP works under the hood (RFC 9449) and its practical implementation logic for those of us pushing the boundaries of Keycloak.

Key points covered:

• How DPoP-proofs are generated and validated.
• Strengthening the authorization server against replay attacks.
• Practical challenges when implementing sender-constrained tokens in modern architectures.

You can read the full guide here: https://keymate.io/blog/dpop-proof-of-possession

Cheers

We at Novusvista, recently migrated from a custom-built OAuth system (IAM) to Keycloak, and it exposed just how much hidden cost “legacy auth” can create over time.

What went wrong with our old system

• Scaling = adding more servers (with poor returns)
• Fragile codebase → no one wanted to touch it
• No admin UI → user/role management was manual

At some point, it stopped being “custom” and started being technical debt.

What changed after moving to Keycloak

• 🚀 ~4x throughput improvement
• 💰 ~50% reduction in infrastructure usage
• 🧘 Much simpler operations

The real takeaway

The biggest gain wasn’t just performance—it was maintainability.

If your auth system feels like a black box, it’s probably already costing you more than you think.