Repository navigation
Replies: 2 comments 6 replies
|
On (3): yes, that's an intended use. Keycloak ships Option A almost verbatim as a quickstart, action-token-authenticator: an authenticator creates an action token for the current auth session, redirects to an external app, the app returns through the action-token URL, and the handler resumes the flow. Worth copying from ExternalAppAuthenticator:
On (4): Keycloak's default CSP is just My take (opinion, not an official position): for something you'll reuse in reset-credentials and step-up, A ages better. The SCA UI is an app you own and deploy on its own, not a theme you re-test on every Keycloak upgrade, and Keycloak only sees "left, came back with a result". On (6): mostly right. On (5) I'm not aware of anything official for a fully external login UI; themes (FTL or Keycloakify) are still the way as far as I know. |
|
Thank you very much for the reply! Based on your recommendation we should go with approach A, but after diving a little bit deeper into both approaches, we started considering heavily option B. The main benefit is that is removes some of the complexity, which handling the redirect and session management introduce. For the option B, we were thinking of introducing our own custom SCA ftl, which we will modify using Keycloakify. Maintaining it should not be a big issue, as we are not modifying existing theme, so KC upgrades might not be a big deal. We were also thinking of encapsulating this whole login in SCA authenticator, which will handle the eligibility logic and present our custom SCA theme based on that. So i guess, it would be easy to plug it in different flows later like reset credentials, step-up authentication, ect. We are still in talks with the business about weather we need to have SCA in another domain and reuse it for different initiatives. If that is not a requirement from their side, is the approach with custom theme and modification through Keycloakify considered a better one as it is less complex? Glad to hear what are your thought on this? |
|
If nobody needs the SCA UI outside Keycloak, I'd go with B too. Your POC is better evidence than anything I said: the redirect and session handling in A only pays off when the UI has to live on its own domain or be reused by apps that aren't Keycloak. And since the decision stays in A few things I'd settle early with B: The upgrade argument is smaller than it looks, but not zero. The Authenticator SPI is flagged internal too (AuthenticatorSpi L32-34), so Keycloak logs the same "internal SPI, may change without notice" warning for your authenticator as it would for an action-token handler (KeycloakProcessor L733-734). B has one internal SPI instead of two, so keep the authenticator in your upgrade tests either way. Keycloakify only builds The approval window has to fit inside the auth session, whose lifespan is the largest of the realm's login timeouts (SessionExpiration L27-36). Make the push challenge expire before that, so a late approval never lands on a dead session. For reset credentials, pick the position carefully. The default flow is choose user → reset email → reset password (DefaultAuthenticationFlows L172-193). Right after Choose User, anyone who types a username can fire push prompts at that person; after the email step, only someone holding the link gets there. For step-up, the same authenticator can go under a Conditional - Level Of Authentication subflow in the browser flow. |
|
Great thanks for the advice, it was really helpful! All in all, as discussed i think the more reasonable option is B. Our main idea is to unify all of our login journeys to go through Keycloak, therefore a SCA UI within the same domain seems like the right approach. Moreover, another argument against having external domain is that we do not have plans to sell it as a separate feature, but we rather want it for internal use. Thanks, a lot also for the other advices in regards to the caveats of option B. We are currently actively researching how we could integrate the SCA UI within Keycloak for the other flows such as step-up authentication and reset credentials and such valuable insights are very beneficial for us. Thanks again for the advice, we will try to go with approach B and see how it would work out for our use cases🙌 |
|
Glad B fits your setup, and good luck wiring it into step-up and reset credentials. If this thread ended up answering your question, would you mind marking it as the answer? It'll make it easier for others weighing the same SCA options to find. |
|
One detail worth adding to the quickstart recommendation: action-token processing does not always resume the original authentication session. The [26.2.4 documentation](https://github.com/keycloak/keycloak/blob/26.2.4/docs/documentation/server_development/topics/action-token-handler-spi.adoc) says that when the authentication-session ID does not match, the handler can start a fresh session. You can reject that through For your SCA flow, I would explicitly reject a session mismatch if the approval belongs exclusively to the original login attempt. Otherwise, an expired session or a return in another browser context could behave differently from “resume this exact flow.” I would also treat these as separate checks:
Bin 8000 d the challenge to the authentication attempt and purpose, and consume completion atomically so duplicate callbacks cannot reuse an approval. The documentation also notes that single-use action tokens are invalidated when authentication completes, with additional handling needed for flows using multiple action tokens. On A versus B, I would lean toward B if an independently deployed SCA UI is not already a requirement. Keeping the form inside the authenticator reduces the cross-application return handling you need to maintain. A makes sense when owning and deploying that UI separately is important. The [current developer guide](https://www.keycloak.org/docs/latest/server_development/index.html#_action_token_handler_spi) labels the action-token handler SPI as internal, so I would include extension compatibility checks in upgrade testing for A. Useful tests for either design would be: expired login session, two simultaneous tabs, duplicate submission, cancellation followed by late approval, and a password-reset challenge presented during login. These are documentation-based suggestions; I have not reproduced your custom flow. Is your external SCA UI already deployed, or would you build it specifically for this integration? |
|
Thanks for the reply! We have currently just build up the APIs for the SCA. We do not have an externally deployed SCA UI and we are planning on building it for the above mentioned integration. The idea is that we wanted to have it like a reusable component and we want it to plug it in different flows like reset credentials (users are SCA challenged, before they are able to change their credentials), login, step-up authentication (we are planning on using the IAM system as the SCA owner and plugging it in also for the sensitive operations). That is why we wanted to ask, which of the above mentioned options are better suited for our use case, before building on our custom UI on external domain or using Keycloakify to create a new SCA theme. From what you guys mentioned the approach that fits best for us would be based on the fact weather we have a requirement to have the SCA UI on external domain (for example we want to reuse it for separate initiative) or we could host it on the KC domain. Moreover, we have done a POCs on both approaches and the one with the To sum up, I guess if we do not have a concrete requirement for having the SCA UI on external domain the recommendation is to go with the custom theme with Keycloakify approach? |
|
Thanks for clarifying. Given that the UI is being built specifically for Keycloak and there’s no requirement to host it independently, yes-I would choose B for your current use case. Your POCs also support that choice. Reusing the SCA backend and authenticator across flows doesn’t require an externally hosted UI. I would keep the challenge’s purpose explicit login, credential reset, or step-up-and verify server-side that an approval issued for one purpose cannot complete another. The flow-placement and upgrade-testing points in @AZapata27 ’s latest reply are useful additions. Once you have B working, testing expired sessions, parallel tabs, duplicate submissions, and late approvals would be the next practical milestone. |
Uh oh!
There was an error while loading. Please reload this page.
Hi all,
We’re moving Strong Customer Authentication (SCA) into Keycloak and would like advice on the recommended way to build it.
Context
Option A: custom authenticator + redirect to an externally hosted SCA UI (action token)
Option B: custom authenticator + custom login theme page (Keycloakify with Angular)
In both options, the final decision is made server-side in the authenticator. We never trust a browser-side “SCA done” signal.
Questions
Thanks in advance for any guidance or pointers to examples.
All reactions