# Multi-provider authentication without rebuilding the login layer > A SaaS authentication starter with email login, 28 social providers, enterprise gateways, admin controls, profile sync, and clear setup limits. Source: https://saascode.ai/inside/auth-multi-provider-saas-auth · Published: 2026-08-21 · Section: fabric --- A SaaS authentication starter should do more than put a password form on the screen. It should let a product choose the identity providers its market uses, keep the login surface coherent, and leave the owner in control after launch. That is the authentication layer included here. The base ships with email and password registration, login, password reset, email verification handling, and a social-provider system. The social registry contains 28 entries measured in the current code: 20 connect directly through the authentication backend and 8 route through an identity proxy. The list spans Google, Apple, Microsoft, GitHub, regional networks, WorkOS, and Keycloak. This is not a row of decorative logos. Each entry carries its setup fields, OAuth scopes, provider type, display metadata, and operational notes. That breadth matters for a simple reason. Authentication is market-specific. A developer tool may need GitHub on day one. A B2B product may need Microsoft or an enterprise gateway. A product aimed at Japan, Korea, or China needs a different set again. The product owner can make that choice without replacing the login architecture. ## What is actually included The email path uses the authentication service for registration and password login. The reset page starts the password-recovery flow, while the verification page consumes a hashed verification token. Email verification itself is an admin-controlled policy: it is off by default in the base, and a server route handles the no-verification signup path. Social login is driven by one registry. Native providers call the backend's OAuth method directly. Proxy providers go through Keycloak and pass an identity-provider hint, so the same login code can reach providers that are not native to the backend. WorkOS and Keycloak are present as the enterprise options. WorkOS is described in code as the gateway for Okta, Azure AD, and SAML; Keycloak can also act as a self-hosted OIDC proxy. The public provider endpoint returns only providers that have been enabled. It merges the owner's saved order with the registry metadata before the login page sees anything. Disabled providers stay out of the response. That keeps the configuration surface separate from the customer-facing login surface. ## Two-factor enrollment, and what it does not yet do The account security page carries a TOTP card. A user scans a QR code with an authenticator app, enters the six-digit code once to complete enrollment, and can remove the factor later. Verified factors are listed on load, so the page reflects real state rather than a local toggle. That is where it currently stops, and the distinction matters more than the feature. Enrolling registers a factor; it does not change how the product signs anyone in. The login path calls password sign-in and grants the session. Nothing in the application, and nothing in the database policies, requires the elevated assurance level that a verified second factor produces. A user who turns on two-factor authentication still signs in with a password alone. So this is an enrollment surface, not enforced two-factor authentication. Wiring it the rest of the way is small — the login flow challenges the factor, and protected paths require the elevated level — but until a product does that, the second factor is registered rather than required. Any product that needs real 2FA should treat that as work to do, not as work included. The database also records which provider created a session profile. On social signup, the profile trigger captures available name and avatar data. A later sync fills missing profile fields when a provider supplies them after the first login, but it does not overwrite a name or photo the user has already chosen. Email is deliberately excluded from that background profile sync because changing an address has its own verification and uniqueness rules. ## What the owner controls The admin API lists all 28 provider definitions with their enabled state, required credentials, configuration status, and sort order. Updating a provider saves the public on/off and ordering configuration separately from its credentials. The login endpoint then reads that saved configuration at runtime. For direct providers, the same admin operation can synchronize the setting with the authentication backend through its management API. That convenience is opt-in. It needs a management access token that is not included in a fresh deployment. Without that token, credentials are still saved, but the response tells the owner to finish activation in the authentication dashboard. That is a useful boundary: the product never pretends it can configure an external identity project without the external authority required to do it. The provider registry is also an extension point. A provider definition says what fields it needs and how it connects. The login handler only needs to know whether the entry is native or proxied. Adding a market-specific option does not require another login system beside the existing one. ## The honest limit The 28 entries are supported configuration paths, not 28 pre-provisioned provider accounts. Google, Apple, WorkOS, Keycloak, and every other external identity service still require credentials and, in some cases, their own review or paid developer account. Apple, for example, carries a code-level note about its developer-program requirement and expiring client secret. There is another limit worth stating plainly. The base has email/password login, password recovery, verification-token handling, social OAuth, and enterprise gateways. It does not have passwordless email login — there is no magic-link or one-time-code sign-in screen. The identity emails the authentication backend sends may themselves carry a link, but a link inside a verification email is not a passwordless login path, and the product does not offer one. Enterprise SSO also depends on the chosen gateway. The registry includes WorkOS and Keycloak; it does not include a home-grown SAML server. That is a good trade. Identity protocols are exactly where a product should integrate a maintained provider instead of improvising one. ## Why this belongs in every product Authentication touches the first session, every protected route, the user profile, the admin panel, and the tenant boundary. Bolting it on after product work starts creates two systems that have to be reconciled under pressure. Starting with one provider registry and one profile model gives each product a stable floor. A small product can enable only email and Google. A regional product can expose the providers its customers recognize. A B2B product can configure an enterprise gateway. The visible choices change. The underlying session and profile path does not. That is the point of the included authentication layer: not to decide how every customer must sign in, but to make that decision a configuration choice instead of a rewrite.