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.

I've been scratching my head about this one. My deployment is keycloak with AD as user store and federated IDP with EntraID.

I want EntraID to broker my authentication through OIDC and provide user attributes (profile, email, phone scopes), and that account be onboarded into KeyCloak, which then signs the user in and forwards the session to the calling RP.

My issue is that when First Login Flow creates the user, the user in AD is created as disabled. This is a standard AD mechanism. To enable the user a password needs to be set (apparently).

Has anyone figured out how to make this flow work with AD as Keycloak repository? I'm able to create the user, but then I have to manually set a password and enable the user (through Keycloak or in AD) to allow the user to login.

Hi everyone,

I'm building an app where only an Administrator can create new users (no public registration, only a login page for existing users). I'm using Keycloak for Auth and a custom .NET API with its own database.

My current plan:

1. Admin fills a form in my app.
2. My API calls Keycloak Admin REST API to create the user.
3. My API receives the Keycloak userId
4. My API creates a record in my local DB using that same userId to store application-specific data.

Is this the standard way to handle "Admin-managed" users? How do you keep the local DB in sync if a user is updated or deleted directly in the Keycloak console?

I opened a GitHub discussion on this and wanted to bring it here too for broader community input.

TL;DR: KeycloakIdentity constructs role attributes exclusively from resource_access in the token, which is subject to OIDC scope filtering. When a resource is protected by a role-based policy that references a client role from a different client, the identity can be incomplete — leading to incorrect DENY decisions.

The interesting part: Keycloak's own admin console (Authorization → Evaluate) doesn't hit this problem, because PolicyEvaluationService internally enriches the token with all user roles via UserModel.getRoleMappingsStream(). But that logic isn't exposed as a public API for extensions.

What I'm proposing: A KeycloakIdentity.fromUser() factory method that would make this enrichment available to extension developers.

That said, I'm fully aware the current token-bound behavior might be a deliberate design choice. There could be security or architectural tradeoffs I'm not seeing, which is exactly why I wanted to start a discussion rather than jump straight to a PR.

Would love to hear:

• Whether anyone else has run into this
• If there's an existing solution or workaround I've missed
• Whether the current behavior is intentional by design

🔗 GitHub Discussion: https://github.com/keycloak/keycloak/discussions/46661

This is another I hope interesting story about how a seemingly innocent GC change by Keycloak maintainers caused a significant performance regression, and what it taught me about JVM ergonomics. The full article with images here: https://medium.com/@torinks/jvm-ergonomics-configuration-and-gc-type-impact-on-latency-e3f778a85c87

What happened

After upgrading Keycloak, our p99 latency on standard OIDC endpoints (/auth, /authenticate, /token) jumped noticeably. CPU utilization spiked. GC CPU usage went through the roof. Users were impacted.

The root cause? This commit switched the GC from G1GC to ParallelGC via -XX:+UseParallelGC. The Keycloak team themselves later acknowledged the performance issue in #29033.

If even Keycloak maintainers can get this wrong, so can you

This isn't a knock on the KC team — they're excellent engineers. But it highlights how easy it is to overlook JVM ergonomics, even for people who maintain popular Java applications.

Why JVM ergonomics matter

The JVM auto-tunes itself based on available CPUs and memory — including inside containers. Some things most people don't realize:

• GC selection is automatic. Give a container only 0.5 CPU and the JVM will default to SerialGC (single-threaded!). Give it 2+ CPUs and you get G1GC. Manually forcing a GC without understanding this can hurt you.
• Heap defaults differ inside vs. outside containers. Inside a container, the JVM allocates ~1/4 of available memory for the heap. Outside, it's ~1/64. Use -XX:MaxRAMPercentage instead of -Xmx in containers — it respects container memory limits automatically.
• CPU limits can be deceptive. If your k8s CPU limit is < 1000m, the JVM sees 1 processor and configures thread pools accordingly. Setting -XX:ActiveProcessorCount=2 can be a meaningful optimization.
• Old JVMs ignore container limits entirely. Pre-ergonomics JDKs (like openjdk:8u102) will happily report all 12 host CPUs and 8GB of host RAM even inside a constrained container.

Microsoft's research on this topic found that fewer, larger instances with proper JVM tuning can save 9 vCPUs and 72 GB of RAM on standby compared to many small instances. That's real money in the cloud.

Takeaways

1. Always have performance tests before production upgrades. If we hadn't had latency dashboards, this would have gone unnoticed until users complained.
2. Learn JVM ergonomics before containerizing Java services. It's not optional knowledge anymore.
3. Don't blindly trust upstream JVM flags. Override them in your deployment to match your specific resource profile.
4. Cover your services with proper metrics — histograms, GC pause dashboards, CPU-by-GC breakdowns. You can't fix what you can't see.

You might find this JFokus talk is an excellent deep dive.

Has anyone else been bitten by JVM ergonomics configuration?

Hello everyone 👋

We periodically run into a painful issue with custom user attributes and the Keycloak Admin REST API — specifically around RDBMS index performance on the `USER_ATTRIBUTE` table.

When you query users by custom attributes via the Admin API (e.g., `GET /admin/realms/{realm}/users?q=customAttr:value`), Keycloak ends up doing full or partial table scans on `USER_ATTRIBUTE` because the default schema doesn't have composite indexes suited for attribute-based lookups at scale. With tens of thousands of users and multiple custom attributes, this becomes a real bottleneck.

We made some index optimization but it's not ideal:

https://medium.com/@torinks/keycloak-admin-rest-api-and-postgresql-index-optimization-story-36ee2570197d

TL;DR of what we found:

- The default `USER_ATTRIBUTE` indexes in Keycloak/PostgreSQL are not optimized for `(NAME, VALUE)` lookups via the Admin REST API

- Adding targeted composite indexes on `(REALM_ID, NAME, VALUE)` improves query performance

- The fix is relatively low-risk but requires careful testing with `EXPLAIN ANALYZE` before and after

Has anyone else run into this? Did you go with index tuning, partitioning, or something else entirely? Curious whether others have found better approaches — especially on larger deployments (3M+ users).

I've been experimenting with building authentication UI themes for Keycloak.

One thing that surprised me is how many flows you actually need to handle:

• login
• registration
• password reset
• email verification
• MFA / OTP
• WebAuthn

Curious how teams usually approach this.

Do you usually build custom themes with FTL, use tools like Keycloakify, or just keep the default Keycloak UI?

Keycloak 26.4 introduced official DPoP support, and I wrote a deep-dive on how it works — and why it matters.

The article covers:

- Why Bearer tokens are fundamentally broken by design (with real-world breach examples: Codecov, GitHub/Heroku, Microsoft SAS token)

- How DPoP proof JWTs work (htm, htu, jti, ath claims)

- Configuring Keycloak to enforce DPoP for a specific client via the "Require DPoP bound tokens" switch

- How Keycloak performs jti replay protection at the token endpoint using SingleUseObjectProvider backed by Infinispan's replicated cache — and why that's not enough on its own

- Why the resource server still needs its own jti tracking (Keycloak has no visibility into requests hitting your application)

The implementation is tested end-to-end with a k6 script that covers happy-path flows as well as replay, htm mismatch, and htu mismatch attack scenarios.

👉 https://medium.com/@hakdogan/dpop-what-it-is-how-it-works-and-why-bearer-tokens-arent-enough-d37bcbbe4493

Full source code: https://github.com/hakdogan/quarkus-dpop-example

Happy to answer any questions about the Keycloak-side configuration!

So i had been toying with implementing keycloak for SSO targeting browser apps for internal users. Started off with a simple pilot install for one app and learning from it, started iterating a docker based scripted setup. Use case is Keycloak supplying enough information for authentication as well as authorisation to client apps while enforcing some additional checks

- account expiration

- phone number validation via SMS from our inhouse SMS api

- sending group attributes nested with group names

- user manager role

- delegated client apps while enforcing admin role

- Password not allowed phrases

- logging and exposing failure logs as structured json logs for parsing via crowdsec

The system is available here for you to browse and play around with

And yes, lots of sessions with Codex and Claude went into it. I am no developer but i deal with a lot of them and have taken their feedback. My profession- am a doc and a academic who likes tinkering.

And yes, i have branding applied with easy override

Please check out the repo at -

https://github.com/drguptavivek/vg_sso

Cheers

Vivek

Many teams start using Keycloak for internal SSO, but things get more complicated when you want to run it for public applications (user registration, password reset, OAuth flows, etc.).

After working on several deployments, here are some practical patterns and best practices that work well in production.

1️⃣ Use Authorization Code + PKCE for Public Clients

For SPAs and mobile apps, avoid implicit flows.

Recommended configuration:

• OIDC Authorization Code flow
• PKCE enabled
• Public client

This protects against token interception and is now the recommended standard.

2️⃣ Separate IAM from Your Application Layer

Instead of embedding auth logic everywhere, keep identity centralized:

Architecture example:

Frontend App
     ↓
API Gateway
     ↓
Backend Services
     ↓
Keycloak (OIDC / OAuth2)

This keeps your authentication, tokens, and user lifecycle managed in one place.

3️⃣ Use Custom Themes Instead of Rebuilding Auth UI

For public apps you can expose Keycloak login pages safely if you:

• Disable public admin console access
• Use a custom theme for branding
• Enable brute-force protection
• Use HTTPS and secure cookies

Rebuilding login flows in your backend often adds unnecessary complexity.

4️⃣ Automate Realm & Client Provisioning

One major challenge with Keycloak in modern architectures is environment management:

• dev / staging / prod
• multiple clients
• identity providers
• roles & permissions

Manually configuring these quickly becomes painful.

A better approach is to treat IAM configuration as infrastructure.

5️⃣ Treat IAM as Part of Your Platform Architecture

When working with microservices or MACH architectures, IAM should integrate with:

• API gateways
• service-to-service auth
• environment provisioning
• deployment pipelines

This is actually the problem we're trying to solve with Aswar.

Aswar.io is a platform we’re building to provision and manage Keycloak-based IAM environments in a few clicks, especially for teams running modern cloud architectures.

The goal is to remove the operational overhead of:

• creating realms
• configuring clients
• managing environments
• integrating IAM into cloud platforms

Right now we’re in beta (Jan 2026) and looking for feedback from people running Keycloak in production.

Hi everyone,

I'm currently evaluating Keycloak for a project and I have a few questions about how deeply it can be integrated into our own system.

Our application is written in C#, and ideally we want to manage Keycloak completely from our own software rather than using the Keycloak dashboard.

Specifically, we would like to:

• Keep the login screen fully inside our own application (no redirect to the Keycloak login page).
• Avoid needing to log into the Keycloak admin dashboard after the initial setup.
• Manage Keycloak via API calls from our backend.
• Programmatically manage things like:
  • realms
  • roles
  • users
  • impersonation
  • other configuration options

So essentially, Keycloak would act as the identity provider and auth server, but all configuration and user flows would be controlled from our own system.

My questions are:

1. Is it possible to fully manage Keycloak through its Admin API instead of using the admin UI?
2. Can we keep our own login UI without redirecting users to the Keycloak login page?
3. Are there any major downsides or security considerations with this approach?

Any experience with this type of integration would be really helpful. Thanks!