Choosing an authentication UI is not a styling decision. It decides which origin receives credentials, where session cookies live, how quickly security fixes reach users, and how much protocol code your team owns.

There are three practical models: redirect to hosted authentication, embed vendor components in your app, or build a fully custom UI over authentication APIs. None wins every category. The right choice depends on the trust boundary you want to operate.

The decision in one table

Model	Credentials handled by	Security maintenance	Brand control	Integration effort
Hosted Auth	Dedicated auth origin	Lowest for app team	High with branding/custom domain	Lowest
Embedded components	Your application origin	Shared	Higher	Medium
Fully custom UI	Your code and origin	Highest	Complete	Highest

For most teams, start hosted. Move toward embedded or custom only when a concrete product requirement justifies the additional browser and maintenance risk.

Draw the trust boundary before comparing screens

The three models can look almost identical to a user. The difference appears in the browser execution context.

Hosted
app.example.com -> accounts.example.com -> app callback -> app session
                       credentials
 
Embedded or custom
app.example.com
  application + analytics + dependencies + credential UI + auth SDK

With hosted authentication, credential collection runs on a dedicated identity origin. With embedded or custom authentication, it runs on the same origin as the application and its scripts. That changes which compromise can observe an OTP, alter a recovery link, replace a passkey prompt, or redirect a session result.

This is why “we can match the same CSS” is not a security comparison. Start with origins, scripts, cookies, callback validation, and operational ownership. Choose styling after that.

Hosted authentication

Hosted Auth redirects the browser to an environment-specific page such as:

https://your-project-test.id.namoid.in/sign-in

The identity service renders email OTP, password, passkey, waitlist, and other enabled methods. After authentication, it returns a one-time result to the application callback, which creates the application's own session.

Where hosted auth wins

Credentials are entered on a dedicated, tightly controlled origin.
Security and accessibility fixes deploy once for every integrating app.
CSP can be narrower than on a feature-rich application origin.
New authentication methods can appear without rebuilding every app form.
The integration has less state-machine and error-handling code.

Hosted does not mean unbranded. Logo, colour, copy, legal links, and custom domains can make the page part of the product journey. A custom auth domain such as accounts.example.com also gives users a recognizable first-party hostname while preserving the operational boundary.

Hosted auth trade-offs

Redirects create a visible navigation boundary. Poorly configured domains can feel like phishing, and strict browsers may partition cookies across unrelated sites. The application must also validate the callback and establish its own session; a successful hosted sign-in is not automatically an authorization decision inside the app.

The callback needs the same care as any security endpoint. Validate the one-time result, state, expiry, intended return URL, environment, and proof challenge where the flow uses one. Consume the result once, then establish an HttpOnly application session. Never accept an arbitrary post-login redirect merely because it arrived from the sign-in page.

Embedded authentication components

Embedded components render inside the application but delegate behavior to an SDK. They can produce a smoother modal or inline experience and share the application's design system.

The trust boundary changes: credential fields and authentication JavaScript now run alongside your application code, analytics scripts, tag managers, and dependencies. A cross-site scripting flaw has a larger blast radius because malicious code can observe or manipulate the authentication experience.

Good embedded components should still provide:

Secure defaults for OTP, passkey, and password flows.
Generic account-enumeration-resistant errors.
Accessible loading, retry, and recovery states.
Browser-safe publishable-key configuration.
A server-side session exchange rather than tokens in localStorage.

Embedded components reduce UI work, not security ownership. Your deployment's CSP, dependency graph, and origin hygiene become part of the authentication system.

They also create a versioning question. A vendor may release a fix, but users receive it only after your package update, deployment, cache refresh, or runtime loading model takes effect. Define who watches advisories and how quickly critical auth-component updates reach production.

Fully custom authentication UI

A custom UI calls authentication APIs directly and owns every transition. It is appropriate when the authentication journey is deeply coupled to domain onboarding, regulated disclosures, device workflows, or unusual accessibility requirements.

It also means owning the edges users hit in production:

Resend invalidates the previous OTP.
Unknown and known identifiers do not produce distinguishable responses.
Waitlisted applicants do not accidentally become users.
Passkeys are offered only when appropriate for the selected account and device.
Expired flows recover to a safe starting page instead of rendering raw JSON.
Rate limits, CAPTCHA, cooldowns, and email notifications compose correctly.

These are not theoretical details. They are the bulk of authentication engineering after the first successful login works.

A custom form can still use a managed identity backend. “Custom UI” does not have to mean “write password hashing, WebAuthn verification, session rotation, and abuse detection yourself.” Keep protocol and credential verification behind supported server APIs, and treat browser-facing publishable configuration as public. Server credentials never belong in the custom frontend.

Compare who owns each failure mode

Authentication failures span browser UI, identity state, and application sessions. Use an ownership matrix before selecting a model.

Failure mode	Hosted	Embedded	Fully custom
Credential-form rendering	Identity provider	Shared through component SDK	Application team
Form accessibility	Identity provider	Shared	Application team
App-origin XSS	Less direct exposure to credential entry	Directly relevant	Directly relevant
OTP and password verification	Identity provider	Identity provider	Identity provider if API-backed
Abuse controls	Identity provider, plus app entry controls	Shared	Shared, with more app orchestration
Callback and app session	Application team	Application team	Application team
Authorization inside product	Application team	Application team	Application team
Branding integration	Configuration/custom domain	Component theming	Application code
Security-fix rollout	Central provider deployment	Package/runtime update may be needed	Application deployment

No model outsources product authorization. The identity result says who authenticated and with which claims. Your application still decides whether that identity can view an invoice, administer a tenant, or access a regulated workflow.

Cookies and custom domains

An authentication provider cannot set a cookie for an unrelated customer application domain. Hosted Auth therefore uses a secure handoff: the auth origin maintains its own session, then the application callback creates an application-owned session cookie.

Custom domains improve continuity but do not erase origin boundaries. accounts.example.com still cannot set a host-only cookie for app.example.com; the callback remains the clean place to establish the app session.

Use HttpOnly, Secure, and an appropriate SameSite value. Do not place access or refresh tokens in localStorage. Rotate or revoke the application session independently from the identity provider's browser session.

Do not broaden a cookie to .example.com merely to avoid the callback. A domain cookie may become available to every matching subdomain, expanding the set of services that can interfere with it. Host-only cookies and an explicit handoff usually produce a clearer boundary.

CSP and XSS blast radius

Hosted pages can run a narrow Content Security Policy because they need fewer third-party scripts. Embedded authentication inherits the application CSP, which is often broader due to analytics, support widgets, payments, and experiments.

This does not make hosted pages invulnerable. Supply-chain security, output encoding, CSRF controls, and secure cookies still matter. The advantage is isolation: fewer scripts and a smaller code surface execute where credentials are entered.

For an embedded model, inventory every script allowed on the page. Tag managers that can inject arbitrary code, customer-support widgets, experimentation platforms, and compromised npm dependencies all share the origin's power. A strict CSP helps, but a policy containing broad host wildcards or unsafe-eval may offer less protection than its presence suggests.

Hosted pages should avoid unnecessary third-party scripts too. A dedicated origin is valuable only if it stays dedicated.

Branding versus conversion

A familiar, fast login flow usually converts better than a novel one. Custom UI can remove a redirect and match a product precisely, but it can also introduce confusing method choices, inconsistent recovery, and mobile layout bugs.

Measure completion rate by method and step before replacing hosted pages. If the real issue is an unfamiliar hostname, add a custom domain. If it is copy or visual hierarchy, use branding controls. Take on a custom authentication state machine only when those options cannot solve the measured problem.

Measure recovery and accessibility, not just happy-path conversion. Track completion by device, browser, method, and step; error recovery; OTP resend use; passkey fallback; and time to completion. Review the experience with keyboard navigation, screen readers, zoom, reduced motion, and small mobile viewports.

A one-point conversion change is not automatically worth a larger credential-handling surface. Include security review, support load, release maintenance, and incident blast radius in the decision.

Hosted Auth is not the same thing as OAuth

Hosted authentication describes where the sign-in experience runs. OAuth and OpenID Connect describe authorization and identity protocols. They often appear together, but one does not require the other.

An application can use a native hosted-auth handoff: redirect to its environment's NamoID Auth page, receive a short-lived one-time code, exchange it through the supported backend flow, and create its own session. It does not need to create an OAuth Application merely to use hosted sign-in.

Separately, an application can register an OAuth/OIDC client when it needs standards-based authorization, federation, or “Sign in with NamoID” behaviour. That client may still use the same hosted pages to collect credentials. The UI location and protocol contract are separate choices.

Keeping those concepts separate prevents two common mistakes: building an OAuth consent flow for a first-party login that does not need delegated authorization, and assuming a hosted page can directly set the customer application's session cookie.

A practical selection rule

Choose Hosted Auth when you want the smallest security and maintenance surface.

Choose embedded components when in-app continuity is a measured requirement and your application origin has strong CSP and dependency controls.

Choose a fully custom UI when authentication is itself a differentiated workflow and your team is prepared to test abuse, recovery, accessibility, and browser edge cases continuously.

Before deciding, answer this worksheet:

Which user requirement cannot be met through hosted branding or a custom domain?
Which scripts execute on the application sign-in route?
Who owns auth UI security and accessibility releases?
Where will credentials, one-time results, and session tokens appear?
How does the application validate the handoff and create its cookie?
Which recovery and abuse states have automated tests?
What metric will prove the more complex model is better?
What is the rollback path if it is not?

If the team cannot answer these questions, hosted authentication is the safer starting point.

NamoID Auth starts with hosted pages because that is the safest default for small teams shipping quickly. Publishable-key SDKs and custom UI primitives can extend the model without weakening secret-key boundaries. The product should let a team move deliberately along this spectrum, not force every customer to begin at its most complex end.

FAQ

Is hosted authentication always more secure?

It usually reduces the customer application's credential-handling surface and centralises fixes. It is not automatically secure: the provider must still protect its origin, flow tokens, callbacks, cookies, dependencies, recovery paths, and infrastructure. The application must securely validate the handoff and manage authorization.

Hosted vs Embedded Authentication