Skip to main content

Consumer access quickstart

SecureAuth Connect consumer workspaces provide authentication for public-facing applications where users create and manage their own accounts. Supported features include self-service sign-up, social login, passkeys, MFA, and branded sign-in flows.

What is consumer identity?​

Consumer identity manages sign-ins for applications your customers use:

  • Scale traffic spikes without interruptions. Your sign-in infrastructure needs to handle millions of users and sudden traffic spikes during campaigns and product launches.
  • Let users self-serve. Customers can sign up, reset passwords, and recover accounts on their own. No support tickets, no admin overhead.
  • Give users the login options. Users expect to sign in with email and password, Google, Apple, or another social provider, plus passwordless options like passkeys and one-time codes.
  • Consumer trust and privacy. The sign-in page is the first thing customers see. Privacy laws like GDPR and CCPA govern what you can collect and how users revoke consent. Getting this right protects both your brand and your compliance posture.

What you'll set up​

This guide walks through connecting a consumer application to SecureAuth Connect. By the end, users can register themselves, sign in with email and password or a social provider, and land authenticated in your application.

  1. Create a consumer workspace – your isolated environment for users, applications, and policies
  2. Set up sign-in and sign-up – choose how users create accounts and authenticate
  3. Test with the built-in User Portal – verify your setup without writing any code
  4. Connect your application – register your application and get framework-specific integration code
  5. Add features – MFA, branding, and a custom domain when you're ready

Create a consumer workspace​

A workspace is your isolated authentication environment: it holds your user directory, registered applications, and sign-in policies. Select Consumer Applications and Services when creating it; this type pre-configures the settings consumer applications need, including support for social login, passkeys, and self-registration.

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.

Self-registration is off by default. To let users create their own accounts, 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.
  • Email OTP – Let users sign in with a one-time password (OTP) sent to their email address.
  • 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.

The Sign-in and Sign-up tab in the BlixitShop workspace showing First-Factor Authentication Methods with Email OTP and Password configured, and a Second-Factor Authentication Methods section

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. The User Portal application settings page showing the Application URL field highlighted with a red box and the external link icon used to open the sign-in page
  3. Click Sign Up and register with your name and email address. Check your inbox for a verification code to activate your account, then confirm you land in the User Portal. The User Portal sign-in page showing log in with email code, a Password option, and an arrow pointing to the Sign Up link
  4. If you enabled a social provider, sign out and sign back in using that provider. Confirm that you land in the User Portal. The User Portal sign-in page showing Google and Users sign-in options, with an arrow pointing to the Google option
  5. 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. The Users page in the BlixitShop workspace showing one registered user with an Active status

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.

Select the guide for your application:

Once registered, your application includes a Quickstart tab with framework-specific integration code pre-filled with your Client ID, Issuer URL, and redirect URI.

The Create Application page in SecureAuth Connect showing application type options including Single Page, Server-side Web, and Mobile/Desktop

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 – Access tokens expire after 60 minutes by default, meaning users are re-authenticated frequently. Adjust token lifetimes based on how long your application should keep a user signed in.

See also​