Logo / Docs

Auth as a Service

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

Problem

You have an application that you want to add authentication features to. You also want to safely store users’ personal identifiable information and credentials.

Solution

With the auth as a service use case, after integrating FusionAuth with your application, you can add a variety of authentication and authorization features to your application or applications using configuration rather than coding.

Additionally, as FusionAuth improves in security and functionality, you’ll be able to enable the features without any further code changes to your application or applications.

This is an example of the Local Login and Registration Mode and is the foundation of most other use cases.

Prerequisites

You have a running web or mobile application that has some kind of login flow.

You have a FusionAuth instance up and running.

Example Scenario

Suppose you have an e-commerce store, where people can buy clown costumes. You want to:

  • let the user log in easily, using social logins or magic links
  • let the user register
  • enable MFA
  • verify user emails

Actors/Components

  • your user and their client application (mobile app or browser)
  • your application
  • FusionAuth

Implementation Steps

This is a two step implementation to ensure your customers will always be able to buy clown wigs and red noses. First you need to integrate with FusionAuth, then you need to configure FusionAuth to enable desired features.

Here’s a high level sequence diagram of the application login process before you integrate with FusionAuth.

UserApplicationView HomepageClick Login LinkShow Login FormFill Out and Submit Login FormAuthenticates UserDisplay User's Account or OtherInfoUserApplication

Your application login flow before FusionAuth.

Here’s a high level sequence diagram of the application login process after FusionAuth integration.

UserApplicationFusionAuthView HomepageClick Login Link (to FusionAuth)View Login FormShow Login FormFill Out and Submit Login FormAuthenticates UserGo to Redirect URIRequest the Redirect URIIs User Authenticated?User is AuthenticatedDisplay User's Account or OtherInfoUserApplicationFusionAuth

Your application login flow with FusionAuth.

Integrating With FusionAuth

You need to do the following to integrate with FusionAuth:

  • Create an application configuration in FusionAuth using the admin UI or the API. This corresponds to your clown goods ecommerce store and tells FusionAuth about the login behaviors you want.
  • Choose an integration method. The right option depends on your applications architecture and technology. You can use an OIDC library, one of the FusionAuth SPA SDKs (Angular, React, Vue) or mobile SDKs (Android, iOS coming soon), or a compatible FusionAuth client library.
  • Configure the integration method. The exact steps will vary, but typically includes the client Id.
  • Update your application and add a link or button to send the user to FusionAuth when they need to log in. The correct URL is displayed in the View screen of the application config or you can build it using the example authorization code grant documentation. Some OIDC libraries can generate this URL given a client Id.
  • When your application receives tokens, the user is successfully “logged in”. You should ensure that the ecommerce application considers the user logged in. What exactly that means depends on each particular application, but often involves creating a session and storing user data inside of it.
  • Take additional steps such as examining tokens for roles or sending the token to the browser as a cookie. Again, the exact next steps depend on the application.

Updating FusionAuth Configuration

Now that your application delegates authentication to FusionAuth, additional features can be enabled via configuration. The specific configuration steps depend on the exact feature. You can manage FusionAuth configuration using IaC or other means.

You’ll probably want to update the FusionAuth hosted pages look and feel to match your branding using themes.

Expected Outcome

You’ve delegated your application’s login functionality to FusionAuth. User profile and credential data is securely stored, and you can enable new functionality through configuration, rather than engineering effort.

Edge Cases

If you have user data in your application, you’ll want to migrate it to FusionAuth. Here’s a helpful migration guide.

In your application, after successful login, validate the tokens and the claims provided to ensure the token was provided by FusionAuth for your application.

Ensure you modify the look and feel of the hosted login pages with themes.

The hosted login pages give you maximal flexibility around look and feel customization, but constrain your login flow options. If you want to build login workflows with unique requirements, use the Login API. This is the data store use case. An example custom workflow would be:

  • prompt for an invite code and have the user provide a login Id
  • send the user an MFA challenge
  • present them with a login screen, but only the login Id (email or username)
  • ask for the password on the next page

Other Example Scenarios

Any application which requires a user to log in to access data or functionality matches this use case. Examples include:

  • An online game
  • An AI content editing application
  • A blog
  • A support ticketing system
  • A social network

In each of these cases there’s functionality limited to users based on their identity, profile and permissions.

Additional Documentation