New message text here

Based on the Ory documentation, the recommended approach depends on the type of client and the flow you want to implement: - If your front-end is a browser application (SPA, server-side rendered, etc.): The front-end should initialize the registration flow using the browser endpoint (

/self-service/registration/browser

). The user interacts with the form, and the flow ID is managed in the browser. The back-end should not perform the API flow on behalf of the browser client, as this can introduce security risks (such as CSRF vulnerabilities) and is explicitly discouraged: > Never use API flows to implement Browser applications! Using API flows in Single-Page-Apps as well as server-side apps opens up several potential attack vectors, including Login and other CSRF attacks. [Performing login, registration, settings, ... flows](https://www.ory.sh/docs/kratos/self-service#performing-login-registration-settings--flows) - If your back-end is acting as a native client (e.g., for mobile apps, CLI, or server-to-server): The back-end can perform the entire API flow using the API endpoint (

/self-service/registration/api

). This is appropriate for non-browser clients and allows your back-end to handle the registration process directly, including any extra fields or business logic you need. - Mixing browser and API flows is not recommended: The documentation does not recommend a hybrid approach where the browser creates the flow and then sends the flow ID to the back-end for submission. The flow should be handled entirely by the appropriate client (browser or API/native), not split between the two. Summary: - For browser-based sign-up, the front-end should handle the browser flow. - For back-end initiated sign-up (e.g., for non-browser clients), the back-end should handle the API flow. - Do not mix browser and API flows for a single registration process. If you need to process extra fields, consider using Ory Actions or webhooks, or handle them in your own back-end before or after the Ory registration step, but keep the flow handling consistent with the client type as described above. [Performing login, registration, settings, ... flows](https://www.ory.sh/docs/kratos/self-service#performing-login-registration-settings--flows) [API flows: Native Mobile & Desktop Apps, Command Line Interfaces, Smart TVs and more](https://www.ory.sh/docs/kratos/self-service#api-flows-native-mobile--desktop-apps-command-line-interfaces-smart-tvs-and-more)

Yes, it is expected behavior that a new flow must be created if the current flow has expired. Ory Kratos login (and other self-service) flows have a limited lifetime. If a user waits too long before submitting the form, or if the flow is otherwise expired, the backend will return an error indicating that the flow has expired (for example, with a message like "The login flow expired 1.00 minutes ago, please try again." with error code

4010001

) [The login flow expired 1.00 minutes ago, please try again. (4010001)](https://www.ory.sh/docs/kratos/concepts/ui-messages#the-login-flow-expired-100-minutes-ago-please-try-again-4010001). When this happens, the intended way to proceed is to create a new flow. This is also mentioned in the documentation and community discussions, where it is noted that the application should handle this error case and initiate a new flow for the user [Fetch existing flows](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-basic-integration#fetch-existing-flows), [Github Issue: login flow expired error](https://github.com/ory/network/issues/417). It is perfectly fine—and in fact, recommended—to create a new flow on the spot when you detect that the previous flow has expired. This ensures the user can continue the login process without being blocked by an expired flow. Summary: - If the login flow expires, create a new flow. - This is the intended and documented behavior in Ory Kratos. If you need to check for flow expiration, you can look for the specific error code or message in the response and trigger the creation of a new flow accordingly.

Based on the provided knowledge sources, the recommended approach for API (back-end) registration flows is for the back-end to both create and submit the flow as part of its own process, without involving the front-end in the flow management. The documentation for API flows (intended for native apps, CLIs, or server-to-server scenarios) shows the client (your back-end) initializing the flow and then submitting the registration data directly to Ory Kratos. There is no mention of exposing a "start-flow" endpoint to the front-end or splitting the flow between front-end and back-end. In fact, the documentation warns against mixing browser and API flows, and emphasizes that API flows are for non-browser clients only: > The Registration Flow for API clients doesn't use HTTP Redirects and can be summarized as follows: To initialize the API flow, the client calls the API-flow initialization endpoint ... which returns a JSON response ... > Never use API flows to implement Browser applications! Using API flows in Single-Page-Apps as well as server-side apps opens up several potential attack vectors, including Login and other CSRF attacks. [Registration for API clients and clients without browsers](https://www.ory.sh/docs/kratos/self-service/flows/user-registration#registration-for-api-clients-and-clients-without-browsers) The typical sequence is: 1. The back-end creates the registration flow via

/self-service/registration/api

. 2. The back-end collects the required data (from its own API or other sources). 3. The back-end submits the registration data to the flow's action endpoint. There is no indication in the documentation that you should expose a "start-flow" endpoint to the front-end for API flows. The flow should be managed entirely by the back-end in this scenario. Summary: For back-end (API) registration flows, the back-end should create and submit the flow itself, not expose a start-flow endpoint to the front-end. This is the intended and documented usage for API flows in Ory Kratos. [API flows: Native Mobile & Desktop Apps, Command Line Interfaces, Smart TVs and more](https://www.ory.sh/docs/kratos/self-service#api-flows-native-mobile--desktop-apps-command-line-interfaces-smart-tvs-and-more) [Registration for API clients and clients without browsers](https://www.ory.sh/docs/kratos/self-service/flows/user-registration#registration-for-api-clients-and-clients-without-browsers)

Yes, it is safe to use the API flow in your described scenario—where your back-end both creates and submits the registration flow within a single request—**as long as your client is not a browser application**. The Ory documentation is clear that API flows are intended for non-browser clients such as mobile apps, CLIs, or server-to-server integrations. This approach avoids CSRF risks and is the recommended pattern for back-end-driven registrations: > API flows have three stages: Initialization without redirect and cookies; Form rendering using for example native iOS, Android, ... components; Form submission as

application/json

and payload validation. > ... Never use API flows to implement Browser applications! Using API flows in Single-Page-Apps as well as server-side apps opens up several potential attack vectors, including Login and other CSRF attacks. [API flows: Native Mobile & Desktop Apps, Command Line Interfaces, Smart TVs and more](https://www.ory.sh/docs/kratos/self-service#api-flows-native-mobile--desktop-apps-command-line-interfaces-smart-tvs-and-more) If your back-end is acting as the client (not the browser), it is correct and safe to create and submit the flow in one go. Regarding your alternative: If the front-end starts a browser flow and then forwards it to the back-end for submission, you will lose the browser-specific features, such as auto-login and proper session cookie handling. The documentation warns against mixing browser and API flows, and this hybrid approach is not recommended: > Never use API flows to implement Browser applications! ... [Performing login, registration, settings, ... flows](https://www.ory.sh/docs/kratos/self-service#performing-login-registration-settings--flows) Summary: - For back-end initiated registrations (non-browser clients), use the API flow and handle both creation and submission in the back-end. - Do not mix browser and API flows, as this breaks expected behaviors like auto-login and session management. If your use case requires browser-based auto-login and session cookies, the registration flow should be handled entirely in the browser using the browser flow endpoints. Otherwise, for back-end-driven flows, the API flow is the correct and safe approach.

Ory Kratos issues session cookies for browser-based flows and session tokens for native/API flows. These two mechanisms are intentionally separated for security reasons, and the documentation explicitly states that you cannot break the isolation between cookies and session tokens: > For security reasons, you can't break the isolation between cookies and session tokens. [Session-management overview](https://www.ory.sh/docs/kratos/session-management/overview) Session tokens are intended for non-browser clients (e.g., mobile apps, CLI tools), and are typically sent in the

Authorization: Bearer <token>

header. Session cookies are for browser-based applications and are automatically managed by the browser. While you can use the session token (in a bearer header) for API flows and endpoints that support token-based authentication, this is not a drop-in replacement for cookies in browser-based applications. Some browser-specific features (like CSRF protection and automatic session management) rely on cookies and will not work with tokens. Kratos does support using the session token as an alternative to cookies for endpoints like

/sessions/whoami

and other API flows: > Ory checks for both the cookie and the token, which means that your API must handle both Ory Session Cookies and Ory Session Tokens [Check session status](https://www.ory.sh/docs/identities/sign-in/check-session-token-cookie-api) However, for browser-based flows, you should continue to use session cookies. Switching to session tokens in a browser context is not recommended and may expose your application to security risks (such as CSRF attacks) and break expected behaviors. Summary: - It is safe to use session tokens (in a bearer header) for native/API clients. - It is not recommended to use session tokens instead of cookies for browser-based applications. - Kratos supports both mechanisms, but they are not interchangeable for all use cases. If you need browser-based auto-login and session management, stick with session cookies. Use session tokens for non-browser/native clients only.

The knowledge sources indicate that for registration flows, the Ory Kratos API expects authentication via either a session cookie (for browser flows) or a session token (for native/API flows). The

updateRegistrationFlow

endpoint supports both mechanisms, as shown in the API documentation: - For browser flows, you provide the session cookie in the

Cookie

header. - For API/native flows, you provide the session token in the

X-Session-Token

header. However, if the Ory SDK client you are using (such as

UpdateRegistrationFlowAsync()

) only exposes a parameter for the cookie and not for the

X-Session-Token

, this suggests that the SDK is primarily designed for browser-based flows, not native/API flows. The documentation confirms that the

X-Session-Token

header is supported for API flows, but if your SDK does not expose this, you may be limited in using it for native flows: > |X-Session-Token|header|string|False|The Session Token of the Identity performing the settings flow.| > |Cookie|header|string|False|HTTP Cookies ...| [updateSettingsFlow parameters](https://raw.githubusercontent.com/ory/docs/master/docs/reference/api.json) If you need to use the session token for native/API flows and your SDK does not support passing the

X-Session-Token

, you have two options: 1. Check for an updated SDK version that supports the

X-Session-Token

header for registration flows. 2. Call the API endpoint directly (e.g., using

fetch

,

axios

, or another HTTP client) and set the

X-Session-Token

header manually, as described in the API documentation. If neither option is available, you may be limited to using browser flows with cookies in your current SDK. Summary: If your SDK does not support the

X-Session-Token

header for

updateRegistrationFlow

, you should either use a different method to call the API directly with the required header, or check for an SDK update that adds this support. The knowledge sources do not provide a workaround within the SDK itself if this parameter is missing. [Ory API Reference: updateRegistrationFlow](https://raw.githubusercontent.com/ory/docs/master/docs/reference/api.json)