Fusion has two approaches to providing customer authentication and the management of customer identities.
The first, and recommended approach is using Fusion's redirection which is based on OpenID Connect.
In its simplest form it means that when you need a customer to authenticate or prove their identity to perform an action that requires authorization - your application will redirect to Fusion so that it can perform these trusted functions on behalf of your application.
The second approach is to use our our Authentication API via a custom login form. This approach uses cross-origin authentication. This means that when a customer needs to authenticate, your application (which is a security domain) will send the customer credentials to Fusion (which is another, second security domain). While not recommended, this approach is supported, but can be prone to certain exploits.
1) You can implement industry authentication and customer lifecycle management capabilities with very little development effort.
2) You can change in real-time any aspects of the authentication flow and customer lifecycle management without requiring any code-level changes to your application - all possible through changes to the various Fusion policies like Adaptive MFA, Social Logins, Self-Service and Consent Management.
3) It uses a single security domain for authentication. When a customer logs they are redirected to a login page within the same authentication domain that grants the authentication request, e.g. its performed by your Fusion instance - and is not 'hosted' or part of your application. This mitigates the security risks of cross-origin authentication because its all in the same security domain.
4) There is no user experience to build or custom rebranding required within your application. This is all available through the Fusion Admin Console.
OpenID Connect (OIDC) adds a layer of identity to the OAUTH 2.0 protocol. It allows an application to verify the identity of an end-user via an authentication, performed on an authorization server, and then pull user information, known as "claims". A claim may be something like the users email address.
Typically applications integrate with OIDC providers via a simple redirection flow. When the user desires to login to your application, via clicking a login button or other means, they are redirected to the authorization server for authentication. This authentication can take many forms, including the best practice Adaptive MFA. Once the authentication is complete, the user is redirected to the protected content on the originating site.
The ID Token returned to the originating website contains information about the user, such as the username, email, and other properties. The originating website can use this information as it sees fit. An example would be to load data that is pertinent to the user, like the user's shopping cart.