Skip to main content

Consumer access quickstart

SecureAuth Connect consumer workspaces handle identity for public-facing applications: self-service registration, social login (Google, Apple, and others), passkeys, MFA, and branded sign-in flows backed by a standard OpenID Connect (OIDC) and OAuth authorization server.

What is consumer identity?​

Consumer identity handles authentication for public-facing applications: e-commerce, media platforms, banking portals, and any product where users create their own accounts. It differs from workforce or B2B identity in four ways:

  • Scale and elasticity. Millions of users, with sign-up spikes during campaigns or product launches. Your sign-in infrastructure must handle those peaks without slowing down.
  • Self-service by default. Users register themselves. There is no admin to onboard them, recover their accounts, or rotate their credentials.
  • Many identity sources. Email and password is the baseline. Users increasingly expect social login (Google, Apple, Facebook, Microsoft, X, GitHub, LinkedIn), passkeys, and one-time codes alongside it.
  • Consent and brand. Privacy regulations (GDPR, CCPA) govern what data you can collect and how users revoke it. The sign-in screen is often the first product impression.

SecureAuth Connect supports these capabilities for consumer workspaces: a built-in user directory, social login providers, passkey support, Risk Engine for step-up authentication, and a brandable sign-in experience.

How the pieces fit together​

What you'll set up​

If you have a consumer application (an e-commerce site, a media platform, or a membership portal), this guide walks through connecting it to SecureAuth Connect for authentication. Take BlixitShop, a fictional outdoor specialty retailer: the public homepage is available to anyone, but account features like order history and saved addresses are gated behind sign-in. By the end of this guide, users can register themselves, sign in with email and password or Google, and land authenticated in your application.

Create a consumer workspace​

A workspace is a self-contained authentication environment with its own user directory, applications, and policies. The Consumer Applications and Services type applies secure defaults suited for public-facing apps.

Set up sign-in and sign-up​

Your workspace comes with a built-in user directory. Consumers can create an account with email and password, or sign in directly with Google or another social provider without creating a new account.

To enable email and password sign-up, go to Users, select the Sign-in and Sign-up tab, and in the Sign-up section select the Self registration check box.

Optionally, configure the fields you collect at sign-up under Users > Schemas (name, phone number, custom profile attributes).

SecureAuth Connect supports several first-factor sign-in methods for consumer workspaces:

  • Email and password: The default first-factor method, enabled automatically in a new consumer workspace.
  • Social login: Let users sign in with Google, Apple, Facebook, GitHub, LinkedIn, Microsoft, or X using an account they already have. No new password required.
  • Passkeys: Phishing-resistant, passwordless sign-in using device biometrics or a security key.

For the full list of supported methods, see the Authentication overview.

Test your setup​

Your workspace includes a built-in User Portal application you can use to verify your sign-in configuration before writing any code.

  1. In your workspace, go to Applications > Clients and open the User Portal application.
  2. In the Application URL section, click the launch arrow to open the sign-in page.
  3. Click Sign Up and create a test account with email and password. Confirm you can sign in.
  4. If you enabled a social provider, sign out and sign back in using that provider.
  5. If you enabled passkeys, register one and sign in passwordless.
  6. Go to Users to confirm the account you created with email and password appears in your user directory. Users who sign in through a social provider are not added to the user directory.

Connect your application​

SecureAuth needs to know about your application before it will issue tokens to it. Registering your application creates a trust relationship, generates a Client ID, and unlocks the built-in Quickstart tab.

Choose the guide that matches your architecture:

Each guide leads to the Quickstart tab, where you select your framework and get integration code pre-filled with your Client ID, Issuer URL, and redirect URI.

Add features​

These are independent from the core setup. Add them in any order when you're ready.

Secure sign-ins with MFA and risk policies

Not every sign-in carries the same risk. MFA policies let you require stronger verification only for sensitive actions, and the Risk Engine triggers that step-up automatically based on signals like new devices, unusual locations, or high sign-in velocity.

Brand the sign-in experience

The sign-in page is often the first thing a new user sees. Applying your logo, colors, and copy makes the experience feel native to your product rather than a detour to a third-party service.

Add a custom sign-in domain

Without a custom domain, the browser navigates to a SecureAuth URL during authentication. A vanity domain keeps users on a URL they recognize, for example login.blixitshop.com instead of your-tenant.connect.secureauth.com.

Add more sign-in methods

Passwords are the most common source of account compromise and a leading reason users abandon sign-up flows. One-time passcodes give users a more secure and more convenient alternative.

Next steps​

A working integration is not the same as a production-ready one. Before going live:

  • Custom domain: Configure a vanity domain so sign-in runs on your own domain.
  • Branding: Apply custom branding before users see the sign-in page.
  • Redirect URI: Replace http://localhost:3000/callback with your production redirect URI.
  • Authentication methods: Enable and test every sign-in method you plan to support. A method that isn't configured in production will block users at sign-in.
  • MFA policies: Configure MFA policies for sensitive actions.
  • Notification templates: Verify that verification and reset emails render correctly. Default templates include SecureAuth branding, which most applications will want to replace before users see them.
  • Token lifetimes: Review the default access token (60 min), refresh token (7 days), and ID token (60 min) windows and adjust them for your application's security requirements.

See also​