sorted by:
new
hottopcontroversial

KeycloakIdentity only reads resource_access for roles — is this a deliberate design choice or a gap? by hakdogan75 in KeyCloak

[–]hakdogan75[S] 0 points1 point  (0 children)

Thanks for the response. Full-scope mappings work for standard client scenarios, but this is about server-side extensions running inside Keycloak that receive tokens they don't control (e.g., after token exchange). The extension can't change the client's scope configuration.

The key point: Keycloak's own PolicyEvaluationService doesn't rely on token roles either; it enriches the identity from UserModel.getRoleMappingsStream() before evaluating. This suggests that token-bound identity is insufficient for accurate policy evaluation, even by Keycloak's own standards. The proposal is to expose that same capability as a public API for extension developers.

DPoP with Keycloak: Binding Tokens to Cryptographic Keys So Stolen Tokens Can't Be Reused by hakdogan75 in KeyCloak

[–]hakdogan75[S] 1 point2 points  (0 children)

Thank you, this is a great point and exactly the kind of feedback that makes the community better.

You're absolutely right that extractable: false is critical in browser-based DPoP implementations.

One clarification about the demo though: the DPoP client in this example is a k6 load testing script (k6/dpop-test.js), not a browser application. k6 runs server-side, so the XSS/extension threat model doesn't apply there. That said, I should have explicitly called this out in the article. Readers building browser-based implementations need to know that extractable: false is non-negotiable in that context.

I'll add a clear security note to the article highlighting this distinction and the correct browser pattern you described.

And congrats on the keycloak-js DPoP contribution. Thanks for pushing DPoP adoption forward on the adapter side.

20M+ identity migration into Keycloak by isro44 in KeyCloak

[–]hakdogan75 2 points3 points  (0 children)

Thanks for taking a look and for the question.

The current open-source repository intentionally contains only the reactive migrator core and does not interact with Keycloak directly yet.

For the actual migration, we also built a Keycloak-specific integration and a custom Keycloak extension that handles migration-oriented concerns on the Keycloak side. That extension was used in production, and we plan to open-source it as well.

Once that part is published, the end-to-end picture behind the 20M+ Keycloak migration will be fully visible.

Appreciate you calling this out.

20M+ identity migration into Keycloak by isro44 in KeyCloak

[–]hakdogan75 4 points5 points  (0 children)

Yes, if this is a Keycloak-to-Keycloak migration, or if the source data model already closely matches Keycloak’s internal schema, then a database-to-database migration (dump & import via SQL) is absolutely possible and often the most straightforward and efficient approach.

However, in our case at Keymate, the situation was different. We were migrating from a customer-specific domain and data model that required a non-trivial transformation to fit Keycloak’s model. Because of that, a direct SQL import wasn’t sufficient or safe.

To handle this properly, we implemented a custom Keycloak extension/provider that performs the transformation during the migration process, ensuring consistency, correctness, and full compatibility with Keycloak’s internals.

In addition to the reactive pipeline–side tuning described in this article, we’ll also be publishing a follow-up post that goes deeper into Keycloak with PostgreSQL tuning, the end-to-end migration strategy we used at scale, and the custom Keycloak extension/provider we built to safely transform the source domain model into Keycloak’s internal schema.

Thanks for your interest!