Strivacity has three approaches to providing customer authentication and the management of customer identities.
The first, and recommended approach is using the Strivacity 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 Strivacity so that it can perform these trusted functions on behalf of your application.
The second approach is to use 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 Strivacity (which is another, second security domain). While not recommended, this approach is supported, but can be prone to certain exploits.
Strivacity also supports the ability for any customers to use any Strivacity capabilities with any SAML2 applications. Strivacity acts as an Identity Provider (IdP), offering the major advantage of providing a Single-sign-on experience for any customer accounts across multiple SAML2 applications.
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 Strivacity 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 Strivacity 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 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.
Updated 2 days ago