Sign-in questions, answered.

One account and one sign-in for every site and domain you run.

• How do I share a login session across multiple domains?You can’t share a session cookie between two different domains, because browsers only send a cookie to the domain that set it. Instead, each domain keeps its own session and gets it from one central login, an OpenID Connect provider. Someone who is already signed in there is sent straight back with a one-time code, without seeing a form.6 min read
• How can users log in once and stay logged in on all my websites?Keep one long-lived session at a central login, an OpenID Connect provider, and a separate session on each of your websites. When a site has no session, it asks the provider silently with prompt=none, and people who are signed in there come straight back without a form. Each site renews its own session this way, so people stay logged in everywhere until the central session ends.8 min read
• How do I implement single sign-on across different domains?Use one OpenID Connect provider for all of your domains, and register each domain’s callback URL with it. On every domain, add a route that redirects to the provider with state and PKCE, and a callback that checks state, exchanges the code on your server and starts that domain’s own session. People signed in on one domain then pass through the others without a form.8 min read
• How do I share authentication cookies between two domains?You can’t. A browser sends a cookie only to the host that set it, or to that domain and its subdomains when the cookie has a Domain attribute, and no attribute adds a second domain. Workarounds built on third-party cookies fail in Safari and Firefox. Give each domain its own cookie instead, and share the sign-in through a central login, which is how loginos works.7 min read
• Can I use the same user accounts on multiple websites?Yes. Keep the accounts in one place that every website trusts, usually an identity provider that speaks OpenID Connect, instead of copying users or sharing one database. Each site sends people there to sign in, keeps its own session, and stores its own data under the user’s permanent ID. With loginos, all your domains form one platform with one shared pool of people.7 min read
• How do I set up SSO between WordPress sites on different domains?Install an OpenID Connect client plugin on every WordPress site and point all of them at one identity provider. Each site keeps its own login cookies, but the provider remembers the person, so the other sites log them in after a quick redirect. Multisite domain mapping alone isn’t enough, because WordPress login cookies never cross domains. With loginos, every site’s domain joins one platform.7 min read
• How do I do SSO across multiple Laravel apps on different domains?Let each Laravel app keep its own session and move sign-in to one OpenID Connect provider that all of them trust. Every app gets two routes: one sends people to the provider with state and PKCE, and the other exchanges the returned code, finds the local user by the provider’s user ID and logs them in. With loginos, all the apps’ domains join one platform.7 min read

SaaS products whose customers bring their own domains, and redirect URIs that keep up.

• How do I handle authentication on customers’ custom domains in my SaaS?Let each custom domain run its own sign-in: it sends people to your identity provider and gets them back on its own callback, where your app sets that domain’s session cookie. The provider must accept every custom domain as a redirect target, so register a domain once your records mark it verified and active, and remove it when the customer leaves. loginos does this with one API call.7 min read
• How do I add login to a multi-tenant app where each tenant has its own domain?Resolve the tenant from the request’s Host header, send people to one identity provider to sign in, and check after the callback that the person is a member of that tenant. Keep one user pool for everyone, and store memberships and per-tenant roles in your own database, keyed by the provider’s stable user id. With loginos, every tenant domain goes under one platform.7 min read
• Can I use wildcard redirect URIs with OAuth?Usually not, and you shouldn’t rely on them. RFC 9700, the OAuth 2.0 Security Best Current Practice, requires authorization servers to match redirect URIs exactly, because loose patterns have let attackers steal authorization codes. Google rejects wildcards, while Auth0 and Okta allow narrow ones with warnings. Register exact URIs through an API instead, or use a provider that verifies wildcard ownership or asks your server.7 min read
• How do I add a redirect URI automatically when a customer adds a domain?Call your identity provider’s management API from the code that marks a customer’s domain as verified and active, and add that domain’s callback URL there. Run the call from a job queue so it retries, make it safe to repeat, and remove the URL when the customer disconnects the domain. With loginos you register the host with one POST, or let loginos ask your server.6 min read
• How do I make NextAuth work with multiple domains?Leave AUTH_URL and NEXTAUTH_URL unset and turn on trustHost, so Auth.js builds its URLs from the host of each request instead of one fixed domain. Each domain then keeps its own session cookie, and your identity provider must accept the Auth.js callback URL on every domain. With loginos, someone signed in on one domain comes back on the others without a form.7 min read
• How do I make Supabase auth work across multiple domains?You can’t share one Supabase session between different domains, because supabase-js keeps it in each site’s own local storage or cookies. Give every domain its own session instead, from a sign-in they all trust: an OpenID Connect provider that remembers the person, added to Supabase Auth as a custom provider. With loginos in front, the second domain signs in without a form.6 min read
• Auth0 multiple custom domains is too expensive, what are the alternatives?The main alternatives are one shared login domain for all your brands, one Auth0 tenant per brand, or a self-hosted server such as Keycloak, Zitadel or Authentik, where every domain is yours. Auth0 offers Multiple Custom Domains only on Enterprise. If your real need is many app domains sharing one user pool, loginos fits, but its sign-in page always stays on loginos.io.5 min read

Auth0, Clerk, Keycloak, Firebase and the alternatives, compared on what matters.

• What is a good alternative to Auth0?Good Auth0 alternatives include hosted services like Clerk, WorkOS AuthKit, Stytch, Descope and Kinde, and open-source servers you run yourself, like Keycloak, Zitadel, authentik, Ory and Logto. Firebase, Supabase and Amazon Cognito bundle sign-in with their platforms, and Auth.js or Better Auth keep it in your code. Choose by who runs it and how you would leave. loginos fits products on many domains.7 min read
• What is a cheaper alternative to Clerk?Cheaper alternatives to Clerk are open-source libraries like Auth.js and Better Auth, self-hosted servers like Keycloak, Zitadel or Logto, and the sign-in that comes with Supabase, Firebase or Amazon Cognito. Each saves money by giving something up: Clerk’s prebuilt components, its hosted dashboard, or your team’s time. loginos is a hosted OpenID Connect provider with no paid plans today.6 min read
• Is there a free OpenID Connect provider I can use for my app?Yes. Open-source servers like Keycloak, Zitadel, authentik, Ory Hydra, Dex and Authelia cost nothing to license, but you pay for the server and the upkeep. Hosted services such as Auth0, Zitadel Cloud, Logto Cloud, Kinde and Amazon Cognito have free tiers with limits, and mock servers cover local tests. loginos is a hosted OpenID Connect provider with no paid plans today.7 min read
• What is the best authentication solution for Next.js?There is no single best authentication solution for Next.js; the right one depends on your situation. Clerk and Supabase Auth get a prototype or a social-login app running quickly. WorkOS, Auth0 and Clerk suit B2B apps that need organizations and SAML. Better Auth and Auth.js keep users in your own database, and loginos is a hosted OpenID Connect option for many domains that share one user pool.8 min read
• Is there something simpler than Keycloak?Yes. Keycloak does almost everything, but you run, upgrade and theme it yourself. Simpler self-hosted options include Zitadel, Logto and Casdoor for a full identity provider, Authelia for apps behind a reverse proxy, and Dex for bridging existing directories to OpenID Connect. If you don’t want to run anything, a hosted provider or managed Keycloak removes the operations work, and loginos is a hosted option for apps on many domains.7 min read
• What is a good Firebase Auth alternative?Good Firebase Auth alternatives are Supabase Auth for Postgres apps with row-level security, Clerk or Auth0 for hosted sign-in with enterprise features, Amazon Cognito on AWS, Appwrite for an open-source backend, and Keycloak or Zitadel to self-host. To move, export users with their scrypt password hashes or let people link accounts, and keep each Firebase uid mapped to the new id, which loginos supports through external_id.7 min read

Passwordless sign-in with Face ID, fingerprints and security keys.

• How do I add passkeys to my website?To add passkeys, you use the WebAuthn browser API with a server library. Your server sends a random challenge, the browser calls navigator.credentials.create() to make a key pair, and you store the public key. To sign in, the browser signs a new challenge with navigator.credentials.get() and your server checks the signature. With loginos, passkeys live on loginos.io and need no WebAuthn code on your domains.7 min read
• Is there a service that handles passkey login for me?Yes. Passkey add-ons such as Corbado Connect, the Hanko Passkey API and Bitwarden Passwordless.dev add passkeys to the login you already have, while full auth providers such as Auth0, Clerk, Stytch, Descope and Amazon Cognito run all of sign-in, passkeys included. Compare fallbacks, recovery, domains and data export first. With loginos, your app handles one OpenID Connect callback, and the ID token says whether a passkey was used.6 min read
• How do I implement passwordless login in a web app?You implement passwordless login by replacing the password with something the person has: a passkey, a one-time link or code sent by email or SMS, or an existing Google or Apple account. Passkeys are the only common method that resists phishing, so offer them first and keep an email link or code as the fallback. With loginos you get passkeys with a password fallback, but no email or social login.7 min read
• How hard is it to implement WebAuthn myself?The core is not hard: with a maintained library such as SimpleWebAuthn, registering and checking a passkey takes a day or two. The hard part is everything around it: choosing the RP ID, storing challenges and credentials, several passkeys per person, autofill, account recovery, fallbacks and testing across browsers and password managers. Plan for weeks, not days, or use a provider that has passkeys built in, like loginos.7 min read

Adding single sign-on to an app that already has accounts, without a migration.

• How do I add SSO to an app that already has users?Add SSO as a second way into the accounts you already have, not as a new user base. Let signed-in users connect the new login from their settings, so your app stores the provider’s user id against their account. Keep passwords working while people link, then decide whether to retire them. Never match accounts by an unverified email. With loginos, every token then carries your own user id.7 min read
• How do I migrate existing users to a new login system without making them sign up again?Move the accounts, not the people. Bulk-import users with their password hashes if the new system can verify your hash format, or migrate each person at their next login by checking the old password once. You can also skip the migration: keep your accounts and let signed-in users link the new login. loginos takes that last path, so people keep their account and connect loginos once.6 min read
• How do I link existing user accounts to an OAuth login?Keep a table that maps each provider’s user id, the sub claim, to your own user id. Start the link from a page where the person is already signed in, send state and PKCE, and save the link on your server only after you exchange the code. Refuse a provider account that is already linked to someone else, and never link accounts by email.7 min read
• How can users connect their existing account to a new login provider?Give signed-in users a Connect button in their account settings. It sends them to the provider to sign in and approve, then back to your settings page with a clear confirmation. Your server makes the link only after it checks state and exchanges the code, and it never matches accounts by email. Then show which account is connected, with a way to disconnect it.7 min read

“Continue as” prompts, FedCM, and alternatives to Google One Tap.

• Is there an alternative to Google One Tap?Yes: FedCM, the browser API that Google One Tap uses in Chrome, works with any identity provider, so other providers can show the same kind of prompt for their own accounts. Passkey autofill gives returning users a one-tap sign-in on your own form. Hosted providers also offer “Continue as” prompts, as loginos does for loginos accounts.7 min read
• How do I add a one-tap “Continue as” login to my site?Use FedCM, the browser API behind “Continue as” prompts, with an identity provider that supports it: your page asks on load or from a button, Chrome and Edge show the prompt, and your server checks what comes back. Safari and Firefox need a popup instead. The loginos SDK does both and gives your page a one-time code for your server to exchange.7 min read
• How does FedCM work and how do I use it?FedCM (Federated Credential Management) is a browser API for signing in with an identity provider without third-party cookies or redirects. Your page calls navigator.credentials.get with the provider’s config URL; the browser fetches the accounts itself, shows a “Continue as” prompt, and returns a token only after the person continues. Chrome and Edge support it, and loginos is one such provider.8 min read

Who can do what, defined once and carried in every token.

• How do I put roles and permissions in a JWT?Add them as claims when the token is issued, usually a roles array and a permissions array that the issuer signs with the rest of the token. Before you trust them, verify the signature, issuer, audience and expiry, then check permissions rather than role names. Keep lifetimes short, because a token shows the roles someone had when it was issued. loginos puts both claims in every ID token.8 min read
• How do I manage user roles across multiple apps?Keep roles in one central place, usually your identity provider, and have every app read them from there instead of keeping its own copy. Name permissions per app, like billing:invoices:refund, deliver them in tokens at sign-in, re-check them through an API, and offboard people by blocking their account once. In loginos, one platform’s roles apply on all of its domains.7 min read
• Which auth providers support roles and permissions out of the box?Auth0, Clerk, WorkOS, Kinde and Logto have both roles and permissions built in, and Keycloak, Zitadel and FusionAuth focus on roles. Amazon Cognito only has groups, while Firebase Auth and Supabase leave roles to custom claims you set yourself. The providers differ most in whether roles reach the token by default and whether they are per organization. loginos puts roles and permissions in every token.9 min read