Authentication Overview

The code flow externalizes authentication complexity from OAuth-secured applications, enabling you to update the authentication method without changing code in your apps.

This tutorial summarizes the most common authentication choices you can use when you integrate with the Curity Identity Server, along with links to more detailed tutorials. These resources enable you to use the latest authentication technologies in your applications, and integrate with many types of external authentication systems.

Authenticators

In the Curity Identity Server, an authentication method is called an authenticator. To manage user authentication you run one or more authenticators. You may choose from the built-in options as shown here:

You can create multiple instances of each authenticator. For example, you might use several instances of Saml2 and OIDC authenticators to connect to different external authentication systems.

Plugin System

Authenticators are developed using a plugin system, which you can use to build custom authenticators. Plugins enable you to implement authentication in any possible way, as long as you can design how to collect proofs client-side and validate the proofs server-side:

• When using the system browser for logins, the user interacts with HTML forms
• When using the Hypermedia Authentication API (HAAPI) for logins, the user interacts with native forms

In most cases though, you simply choose a built-in authenticator. The following sections explain the main categories of authenticators that you can use.

Passwords and MFA

Passwords were and are still a common way to manage authentication, so that there are no difficult user prerequisites. All authorization servers provide built-in options for password authentication. In the Curity Identity Server, start with the HTML Forms Authenticator. If it does not meet your requirements, you can use the Username Password Authenticator Plugin as a base for your own custom solution.

Since passwords have multiple security issues it is common to design a multi-factor authentication, by combining passwords with a second option such as:

• Email verification
• SMS verification
• Time-based One Time Passwords, e.g. using the Google authenticator app

Passkeys

Passwords are suboptimal in terms of security and secondary factors can impact usability. These days, passkeys are preferred to passwords, since passkeys provide an out-of-the-box MFA solution based on strong asymmetric cryptography, along with a slick user experience. To use passkeys, you configure an instance of the Passkeys Authenticator.

In many use cases, passkeys enable you to meet your strong customer authentication (SCA) requirements with no need for additional factors. Passkeys are also no less reliable than passwords and can use the same account recovery options. To learn more about getting integrated with passkeys, see the following resources:

• What are Passkeys?
• Passkeys- Design your Solution

Branding Customization

Regardless of the authentication method you choose, it is likely that you want to refine the screens that the Curity Identity Server presents to your users. For this task you use branding customizations. The following tutorials provide some guidance:

• Look and Feel Customization Overview
• Branding Customization Example

External Identity Providers

In many cases, you may need to implement authentication in an external system, to meet use cases such as these:

• Your customers sign into your apps with a social provider like Google
• Your business partners authenticate to your apps using their corporate authentication policy
• Your employees sign into your apps using their employee credentials, e.g. from Microsoft Entra ID

The authorization server typically runs a second code flow to integrate with external systems. External parties can provide App2App authentication, where users authenticate by installing a trusted third-party's mobile app. Read more about the behaviors and your choices in Integrate with Identity Providers.

Authentication Selection

When you configure more than one authentication option for your app, users see an authentication selection screen by default. If you want to avoid a selection screen being part of the user experience, an application can bypass it and go directly to a particular authenticator by including the OpenID Connect acr_values parameter in their code flow's authorization request.

You can use authentication actions to apply custom logic to user authentication. For example, you might determine the authentication method based on a user attribute stored against the user account. For that purpose, you can use the built-in username authenticator to identify the user and then determine the authentication method.

Authenticating Remote Users

Another standard you can use in your authentication solutions is Client Initiated Backchannel Authentication (CIBA). This might enable a call center agent to ask a user to authenticate remotely, then perform limited operations on behalf of the remote user. You can follow the CIBA tutorial to run this type of flow with the Curity Identity Server.

Identity Proofing

Many authentication solutions do not truly prove who the user is. To receive real proof of a user's identity you may need to integrate with third party systems and use their SDKs. For example, iProov can implement facial scanning to truly authenticate a real person. You can integrate this type of solution with the plugin system.

A more complete solution could be enabled by verifiable credentials, where the user presents their a credential using a digital wallet. The credential is asserted by a trusted third party like a government. An authenticator can cryptographically verify the credential to prove a user's identity and to trust user attributes in the credential. You can try out the use of digital credentials by running the following online demos:

• Issuer Demo Application
• Verifier Demo Application

User Registration

In some use cases, you may need users to register themselves using one or more self signup forms. These could capture user attributes that you save against the user account data or to other data sources. User signup can work differently depending on the authenticator(s), so you could implement multiple registration solutions.

Registration should usually require a proof. A simple option might be email verification and a more advanced option might be a verifiable credential. The Curity Identity Server provides some built-in registration forms or you can use the plugin system to develop custom forms. The Migrating to Passkeys tutorial shows one example of using authentication actions to customize user registration.

Conclusion

There are many ways to manage authentication in an OAuth architecture. The Curity Identity Server implements multiple complex authentication standards to enable rich interoperability with other systems. The Curity Identity Server also provides extensibility in the important places, so that you can refine behaviors or implement custom authentication.