# Designing a custom login experience with Ory Network > Plan custom login screens around identity workflows, client security, and session behavior, and understand where Ory Kratos and Ory Hydra fit. Canonical URL: https://www.devobs.io/articles/building-a-custom-login-experience/ By: Owen Park Published: 2026-10-07T08:46:20.904Z Updated: 2026-10-07T08:46:20.904Z Section: Identity A custom login experience should give you control over the interface without requiring you to build credential validation and account-management workflows yourself. Ory documents this separation in Ory Network: Ory Identities, built on the open-source Ory Kratos project, provides identity workflows and APIs for custom interfaces. [Ory Kratos introduction](https://www.ory.com/docs/network/kratos/intro) Plan that interface around the account lifecycle—not just the sign-in form. Registration, recovery, verification, account settings, and session transitions should be deliberate parts of the design. ## Separate presentation from identity workflows According to Ory’s documentation, Ory Identities does not ship an HTML rendering engine. In Ory Network, you can use the Ory Account Experience or build a custom authentication and profile-management interface with Ory SDKs and REST APIs. [Custom interface support](https://www.ory.com/docs/network/kratos/intro) For a custom implementation, establish three responsibilities: - **Presentation:** Own the layout, labels, navigation, accessibility, and explanation of what the user should do next. - **Identity workflows:** Use the identity backend’s authentication and account-management capabilities rather than inventing parallel credential-validation logic. - **Application integration:** Connect workflow outcomes and session state to the application’s signed-in and signed-out behavior. Keep integration code separate from visual components. Aim to make a layout change independent of the logic that communicates with the identity service. ## Design the full account lifecycle Ory’s documentation lists registration, login, logout, multi-factor authentication, settings, verification, and recovery among its self-service capabilities. Use that list as a planning checklist, even if your first release implements only a subset. [Documented self-service flows](https://www.ory.com/docs/network/kratos/intro) Before building screens, write down the intended experience for each relevant journey: | Journey | Interface decisions to make | | --- | --- | | Registration | Which identity fields are required, and what should users do after creating an account? | | Login | Which authentication methods should appear, and where should successful sign-in lead? | | Multi-factor authentication | How will the interface explain the additional authentication step? | | Verification | How will users understand what needs verification and whether they have completed it? | | Recovery | How will someone who cannot sign in find and complete the recovery path? | | Settings | How will users update personal details and authentication settings? | | Logout | What signed-out state should the application display? | Give each journey an entry point, a completion state, and an explanation for unsuccessful attempts. Place recovery access where someone struggling to sign in can find it, rather than leaving it only inside account settings. Do not use the number of finished screens as the completion criterion. Instead, check whether users can move from an entry point to the intended outcome—and understand what to do when they cannot proceed. ## Align forms with the identity model and enabled methods Ory Identities uses JSON Schema to accommodate application-specific identity data models. Its documentation gives examples such as billing addresses, multiple email addresses, and support-staff cost centers. [Identity schema support](https://www.ory.com/docs/network/kratos/intro) Define the identity data your application needs before designing registration and profile forms. Decide which fields belong at registration and which can wait until later account setup. Avoid adding fields merely because the backend can store them. Ory lists passwords, passwordless codes, passkeys, social sign-in, and multi-factor authentication among its authentication capabilities. These provide alternatives to a password-only interface, but they are not a reason to display every option. Choose the methods appropriate to the application, then expose only those configured for the deployment. [Authentication methods](https://www.ory.com/docs/network/kratos/intro) For each selected method, specify the user’s entry point, the next action, and the route to another available method or recovery path when they cannot proceed. ## Choose the client integration before writing handlers Ory documents APIs for browser and native applications and identifies anti-CSRF cookies as part of its browser security model. Choose the integration for your client deliberately; do not assume browser and native request handling are interchangeable. [Browser and native API support](https://www.ory.com/docs/network/kratos/intro) Before implementing request handlers, resolve these questions using the documentation for the chosen flow and client: - Which API operations or SDK methods initialize and complete the flow? - What cookie and CSRF requirements apply? - How should the interface handle an unsuccessful attempt or a flow that can no longer continue? - How does the application determine whether the user has an active session? Treat the documented security requirements as integration requirements, not optional presentation details. Keep network handling and outcome mapping in a dedicated module so that screens use a consistent implementation. ## Make session transitions part of the experience Ory Identities documents session controls for lifespan, refresh, and revocation. Define the application’s session policy alongside the login interface rather than leaving it as a later backend task. [Session management](https://www.ory.com/docs/network/kratos/intro) Write acceptance checks for more than successful sign-in: - Open an authenticated application route without an active session and check the resulting experience. - Let a session expire and check how the application guides the user back to authentication. - Exercise the configured refresh behavior. - Revoke a session and inspect subsequent session validation and protected requests. - Complete logout and inspect both the displayed account controls and subsequent protected requests. Check both what the interface displays and what the application permits. Do not use a visible signed-out state as the sole acceptance criterion. Make session durations and refresh behavior explicit policy decisions rather than assumptions embedded in UI code. ## Separate the login UI decision from the OAuth provider decision Ory Network’s OAuth 2.0 and OpenID Connect service is built on Ory Hydra. Ory documents that the managed service connects to Ory Identities by default, while its headless API also supports integration with an existing user-management system. [Ory Hydra introduction](https://www.ory.com/docs/network/hydra) Treat this as a separate architectural decision from customizing the login interface. For the UI project, start with the identity workflows needed to let users create, access, and manage their accounts. Evaluate the Hydra-based service when you also need to operate an OAuth 2.0 or OpenID Connect provider—not simply because the login page needs custom branding. A practical first milestone is one complete authentication path: a configured method, a custom interface, session-aware application behavior, and an appropriate recovery route. Expand from that working slice into the rest of the account lifecycle. ## Source references - -