You typically integrate FusionAuth into one or more applications. User data will live in FusionAuth (possibly synced with other data stores) and users will auth against it.
FusionAuth is a developer first platform and there are a large number of ways to integrate it into your new or existing applications.
There are three main ways to have your users sign in: OAuth/OIDC, the Login API, or federated authentication.
The first option is to use OAuth/OIDC/SAML. These are standards and FusionAuth should work with any library or application which supports them. If you find a library which supports OAuth or OIDC and does not work with FusionAuth, please open a bug, as we want to know about it. You can also use a FusionAuth client library.
When you use this option, the data your client receives about the user is limited. You can put custom claims in your JWT using lambdas if what you need is in the user or the registration objects.
If this level of integration meets your needs, you’ll have more portability and less lock-in to FusionAuth.
When a user signs in with this API, you receive the entire user object, as well as the JWT.
When you build on top of the Login API, you’re responsible for building the user interface for all login use cases. This gives you more control, as well. You can still use other FusionAuth provided user interfaces for use cases such as the forgot password flow.
Using the the Login API means that since your application will see sensitive user credentials, you’ll need to ensure the application secures such data appropriately. This is in contrast with the OAuth grants, where only the identity provider has access to the credentials, and your application only sees tokens.
When this is used, FusionAuth will defer to the configured systems of record for authentication and authorization. Please consult the Connector or Identity Provider documentation for more information on these options.
Whether you use the Login API, identity federation, or an OAuth grant, you can use additional FusionAuth APIs in your application.
These allow your application to access and modify data not available from OIDC/OAuth or a federated identity.
Common tasks such as registering a user to an application, removing them from a group, capturing a consent, or capturing custom data all are possible via custom APIs.
The upside of using these is the ability to leverage the FusionAuth data model and functionality. The downside is that your application is coupled to FusionAuth.
Hosted Login Pages
You’ll see the phrase "hosted login pages" used throughout the FusionAuth site. These are all the pages that your end user sees when you are hosting your login experience on FusionAuth, as opposed to within your application. These pages are themeable; you can make them look exactly like your website or application.
Using the hosted login pages has a number of advantages. By doing so, FusionAuth handles the complexity of a number of different auth related use cases. These use cases include, but are not limited to, the following:
Changing a password
Two factor authentication
Account lockout by administrative decision or failed attempts
Password validation failed
Breach password detection
Federated log in with IdPs such as Google and Microsoft Active Directory
Advanced self service registration forms
Multi application logout (OAuth front channel logout)
Additionally, when you use the hosted login pages, FusionAuth provides transparent single sign on (SSO) between applications as well as support for localization of the user interface.
The alternative to using the hosted login pages is building your own login experience. You can then use the APIs or an OAuth grant to authenticate your user against FusionAuth. This alternative gives you more control at the cost of more development effort.
Other Integration Points
There are a number of other integration points in FusionAuth beyond the APIs.
Connectors allow you to authenticate against external user data sources, and optionally migrate users into FusionAuth.
Identity Providers allow you to federate authentication decisions to social or standards based providers.
Lambdas allow you to run business logic at certain points in the authentication lifecycle.
Password plugins allow you to use a custom hashing method. This allows you to import user data from existing systems without requiring any user password changes.
Webhooks allow you to send data to external systems when events occur in FusionAuth.