Inferring Registration Flows from Authentication Flows – Challenges Observed

[KaveeshaPiumini]

While working on enabling registration flow inference for passkey use cases in Thunder (under Asgardeo and hosted on GitHub), I ran into a few architectural and runtime limitations that are worth discussing before we extend this feature further.

At the moment, we support generating registration flow graphs by inferring them from authentication flow graphs. This doesn't seems to be working well during the runtime.

Passkey Registration Cannot Be Directly Inferred from Authentication Graphs

Generating a passkey registration flow from an authentication graph is not straightforward. Passkey registration requires an already existing user because the passkey credential is bound to a specific user account. However, registration flows run in a context where the user does not yet exist.

Because of this, simply reusing the authentication flow structure is not enough. We would need to introduce a provisioning step before the passkey node so that the user account is created first. However, adding a provisioning node alone is still not sufficient. In order to provision a user, we must first collect all required attributes needed to create that user. The challenge here is deciding which prompts should be shown to the user, since the required attributes depend on the user schema associated with the application. Determining these required prompts dynamically is a major challenge.

Additionally, the passkey executor behaves differently between authentication and registration contexts. During authentication it operates using challenge and verify modes, while during registration it uses register_start and register_finish modes.

For inference to work correctly, we would need logic that:

• Transforms authentication modes into their corresponding registration modes during graph inference
• Ensures the user is successfully provisioned before executing passkey registration steps

At the moment, this transformation and orchestration logic does not exist in the inference layer.

Provisioning Node Failures Due to User Schema Constraints

Provisioning is tightly coupled with the user schema assigned to the application. Applications that have self-registration enabled are only allowed to create users who conform to their assigned user schema. However, registration flows themselves are currently designed to be application independent.

This mismatch can lead to runtime failures. Even if an inferred registration flow includes a provisioning node, the flow itself is not aware of the required attributes defined in the application's user schema. As a result, the inputs collected from the user during registration may not satisfy the schema requirements. When this happens, user creation fails because mandatory attributes are missing.

Possible Ways We Could Solve This

Option 1 - Application-Aware Registration Graph Inference

One possible approach is to make registration flow inference application-aware. This would likely require moving registration flow inference to runtime. In this model, if an application does not already have a registration graph, we would infer one specifically for that application using the required attributes defined in its assigned user schema.

By doing this, we can ensure that prompt nodes are added to collect all required attributes before reaching the provisioning node, thereby avoiding user creation failures caused by missing mandatory attributes.

However, this approach would likely require us to relax or modify the current requirement that both authentication and registration graphs must exist before an application can be created.

Option 2 - Runtime Adaptive Provisioning Executor

The other option is to make the provisioning executor more adaptive at runtime. Instead of failing immediately when required attributes are missing, the provisioning node could detect which attributes are missing, return a prompt node requesting those attributes, and then retry provisioning.

This approach would allow registration flows to remain reusable and application-independent, while still respecting schema constraints dynamically at runtime.

However, this could lead to a less optimal user experience during registration. Users may be asked to provide additional information only after an initial provisioning attempt fails, which could feel repetitive or exhausting since they may need to enter user creation information in multiple steps instead of completing it in a single, guided flow.

Text Conversion When Inferring Flows

There is also a related challenge around the user-facing text displayed during flows. This issue arises primarily when an application is configured to use Embedded sign-in/sign-up components. When registration flows are inferred from authentication flows, we currently lack a reliable way to transform text semantically for the registration context.

For example, converting “Sign in” to “Sign up” is not possible at the current stage. To handle this properly, we would likely need explicit mappings from authentication-specific translation keys to registration-specific translation keys, ensuring that the text makes sense in the context of registration across all supported languages.

Other Cases Where Inferred Registration Breaks

SMS OTP Registration

SMS OTP based registration can fail if the user schema does not mandate a mobile number

Social Signups (Google / GitHub)

Google or GitHub signup can fail if attribute sub is not present in the user schema.

Open Questions

1. Should registration flows remain generic, or become application-aware?
2. Should provisioning executor become schema-adaptive at runtime?
3. How should we handle text inference — rule-based, mapping-based, or explicit configuration?

[rajithacharith]

I'm more aligned with @senthalan's suggestion during the offline discussion. The application will only have a single flow (without separate authentication, registration flows). During this flow designing there will be grahps for registration, recovery etc..

Hope @senthalan can add the descriptive idea to this discussion