Repository navigation
SCA and Credential Management UI: Keycloakify or External Frontend? #54611
|
Hi everyone, We are integrating our existing SCA services with Keycloak and deciding how to build the following screens:
Login will remain hosted by Keycloak. We expect to use built-in authenticators for standard login and custom authenticators for SCA, with our backend services handling SCA challenge creation and verification. Approaches under consideration
Potential benefits of the external frontend
Keycloakify would keep all screens, including login, in one project with shared styling and fewer cross-application redirects. An external frontend would require maintaining the Keycloak login theme separately. Questions for the communityWhich approach would you recommend for this use case, considering security, integration complexity, and long-term maintenance? Are there limitations around external SCA or credential-management screens that would make Keycloakify the better choice? Thanks! |
Replies: 1 comment 2 replies
|
I'd split it by what each screen does, not by which project it lives in. The pages that create, verify, change or remove a credential should run inside Keycloak, as authenticators and required actions. An external frontend works fine as the "security settings" page that lists credentials and starts those flows. So the choice isn't Keycloakify vs. external. Keycloakify (or plain FreeMarker/React themes) is just how you style the in-Keycloak pages. Why credential operations should stay in Keycloak:
How the external frontend fits in:
For your custom SCA methods (SMS, your backend's challenges):
The docs' secret-question example shows the wiring (auth-spi.adoc#L650-L671). Your required action then shows up in the Account Console's "Set up" button automatically, and works as On your listed benefits:
|
|
Thanks for the detailed explanation and references! The distinction between credential-management overview screens and the actual credential operations makes sense. One thing we'd still like to clarify is the SCA challenge verification UI. We already have external SCA backend services responsible for challenge creation and verification, which our custom Keycloak authenticators would integrate with. Would it be reasonable for a custom Authenticator to redirect the user to an external frontend to complete the SCA challenge, then return to Keycloak to resume the authentication flow? Or would you still strongly recommend rendering these screens within Keycloak using a theme/Keycloakify? We're particularly interested in whether such external redirects can be implemented safely using supported Keycloak extension points, without relying on internal authentication-session APIs. Thanks again! |
|
Yes, that works, and Keycloak's own quickstarts include an example of it.
https://github.com/keycloak/keycloak-quickstarts/tree/c598d34d3b2dd85976ac96614176df351ee1a4d5/extension/action-token-authenticator On "supported extension points": there is no fully public path here. The Authentication SPI and Action Token SPI pages both carry the internal-SPI note ("any new release ... can change it without prior notice"): If you take the redirect route:
If your backend already creates and verifies the challenges and the UI is only "enter the code" or "approve in the app", a form rendered by Keycloak is fewer moving parts: |
Yes, that works, and Keycloak's own quickstarts include an example of it.
authenticate()can pass any JAX-RSResponsetocontext.challenge(), including a 302 to your frontend. The action-token-authenticator quickstart works like this:action()then callscontext.success().https://github.com/keycloak/keycloak-quickstarts/tree/c59…