Use Cases Overview

Easily offload authentication and add features with configuration rather than coding. The user who logs in could be a consumer (b2c) or a business user (b2b). Features include:

• adding a “Log in with Google” or “Log in with SAML” button
• multi-factor authentication (MFA) via SMS, time based one time passwords (TOTP) or email
• login with a one-time password (OTP) or magic links
• passkeys
• self-service registration and profile management
• verification of user account ownership using email messages

Transparently allow users to log in once and switch between your different applications. As you add more applications, they’ll be able to move between them, similar to the GSuite of products, where you can transparently access Google Calendar, Google Drive, and Gmail even though they are on different domains.

This works with both mobile and web applications. You can limit users to a subset of applications and assign different roles per application.

Offer a SaaS software package, where your customers have consumers as customers or users. The end users of the software control their own identity and typically self-register to gain access to your system.

With this case, users typically access your SaaS software using hostnames tied to customers: customerA.example.com and customerB.example.com, or yoursaas.customerA.com or yoursaas.customerB.com.

You can have each customer’s users isolated, so that customer A’s users are distinct from customer B’s users. The users belonging to customer A will be logically isolated and separate from the users of customer B. You can customize the login screens, password rules, allowed login methods (including social login), and security settings for each of your customers. This is common practice when private labeling software.

Or you can allow end users to switch between customers, like a user can do with GitHub organizations. Each user can have different permissions for each customer. This is useful if there are cross cutting users like contractors, who might work with more than one customer account.

Offer a SaaS software package, where your customers have business employees as customers or users.

With this case, users typically access your SaaS solution using hostnames tied to customers: customerA.yoursaas.com and customerB.yoursaas.com, or yoursaas.customerA.com or yoursaas.customerB.com. They may also use an Org Id input form, like the AWS console, which then directs the user to the correct location.

Businesses typically have their own employee directory using tools like Okta, Azure AD, and Google Workspace. They want to control access to your application automatically using tools like SCIM or SAML/OIDC just-in-time provisioning.

You can have each customer’s users isolated, so that customer A’s users are distinct from customer B’s users. The users belonging to customer A will be logically isolated and separate from the users of customer B. You can customize the login screens and identity provider settings of each of your customers. You can translate between the roles at the customer and within your application using our reconcile lambdas. This is common if you are private labeling your software.

Manage authentication and permissions for software programs using the client credentials grant and access tokens. More secure than static API keys, with fine grained permissions and service identity built in.

Self-host FusionAuth and embed it into your Kubernetes cluster, on-prem data center or other environment.

FusionAuth can scale to hundreds of millions of entities (APIs, devices) and you can manage the entire solution via language specific SDKs.

If you ship software to install in private clouds or data centers, FusionAuth can be a lightweight identity broker allowing you to easily add support for your customer’s identity providers. This lets your software easily integrate into your customer’s environment.

Leverage FusionAuth’s documentation on how to configure connections to Azure AD, Okta and more. Your engineering team uses the FusionAuth APIs and SDKs to get user and role data.

Safely manage your users’ third party API tokens in one place. Add new social or enterprise providers as needed. Secure the refresh tokens and other credentials for social providers like Google, Instagram, YouTube, Facebook, Microsoft, and more.

FusionAuth handles the integrations and your engineering team uses one API to retrieve tokens across all social providers.

If you have APIs that others are building on top of, use FusionAuth to manage user data, and want to allow your users to delegate access to their data accessible via your APIs, FusionAuth can handle the full OAuth grant, including custom scopes and customization of access tokens.

In this case, FusionAuth is part of your API strategy, handling user consents and access token generation.

Use FusionAuth as a rock solid user data store, but take control of the login workflows, the user experience, and other aspects of the authentication experience. You have complete control over the location of the data and how your users log in. This can be helpful if you have stringent UX or unique workflow requirements.

Use the Login API and other APIs to create your own user interfaces. Build your own workflows that meet your precise needs. FusionAuth can be the foundation as a simple, secure datastore with unlimited profile data, search capabilities, and security built in.