Skip to content
Authreads

Protocols

Hosted login

A sign-in page served by the identity provider, which the application redirects to.

What Hosted login means

Hosted login means the sign-in page belongs to the identity provider, not to your application. The user is redirected there, authenticates, and is redirected back. Credentials never reach your application, which removes a whole category of responsibility from it.

How it works

The security argument is straightforward. Your application never sees a password, so it cannot log one, cannot store one badly, and is not in scope for the parts of a review that ask how you handle them. Changes to authentication — a new factor, a new anti-automation control — arrive without you shipping anything.

The cost is the redirect. The user leaves your domain and comes back, which is a visible seam, and the page's appearance is bounded by what the provider allows you to configure.

The alternative is a first-party API, where you build the login screen and call the provider behind it. You keep the seamless experience and you take back the responsibility — the credential now passes through your code, and your code is now in scope.

The mistake people actually make

Embedding a hosted login page in an iframe to hide the redirect. Providers block it, it breaks the user's ability to verify the domain they are typing a password into, and it reintroduces the phishing surface the redirect exists to remove.

In Authreads

How this applies here

Both paths are available: hosted, redirect-based login, and a first-party API for products that build their own screen. Per-tenant branding on the hosted page is checked against WCAG AA contrast before it can go live.

Every capability is listed on /roadmap as Available, In progress or Planned. Nothing is described as available here that is not listed as Available there.

Building on any of this?

Tell us what you're putting together. We'll tell you plainly whether Authreads fits it.