When developing digital experiences, it used to be common to implement all security behavior within the application. This provided full control over managing registration and login flows. However, security has become much more sophisticated in recent years with multiple sign-in methods. This includes the current trend of passwordless authentication via WebAuthn-related standards. It is no longer viable to implement authentication workflows within applications.
Most companies now use an identity and access management (IAM) system and implement authentication via an OpenID Connect code flow. All authentication variations are then managed outside of the application code. Meanwhile, the IAM provider continually supports new features to improve a system's capabilities.
Your original access management requirements still exist, though, and indeed have become more intricate. Organizations must manage a registration flow for new users. You will often want to provide choices for the main authentication factor, such as signing in with a familiar personal Google account, a work Azure Active Directory account, or a Yubikey to represent the user's digital identity. You will also likely need secondary factors both during registration and after the primary factor has been verified.
Ensuring Data Integrity in IAM Systems
When implementing an IAM system, you must also ensure the integrity of identity-related data. It is essential that when a user authenticates in different ways you do not duplicate their account or change the OAuth subject claim presented to your APIs. If user identities are ever duplicated, it can cause problems in your business domain that are difficult to correct. Instead, you must achieve the following data behavior. The process of ensuring a single identity is called account linking, and its importance is not always understood.
Creating User Accounts
In an OAuth architecture, accounts can be created in multiple ways. In many online scenarios, a user can register themselves. This may involve filling in a registration form that captures a user's name, email, and other details. Next, the user may need to verify their email by clicking a link with a one-time token. In some corporate use cases, self-signup may instead be disabled, and users are instead provisioned by an administrator application, which uses the IAM system's user management APIs to create the account.
In other cases, the account already exists in an external identity provider (IDP), such as Azure Active Directory. The main role of the IAM system is an OAuth authorization server, which can federate to many IDPs. After the user authenticates for the first time, they can be auto-created in the IAM system from external attributes. You may also want to store further identity fields about the user, such as their country. So, at this point, you may still need to present a registration form:
Future Authentication Methods
Often, users will have an existing username and password stored in the IAM system. You can then easily add a new method, such as a social login via Facebook, and present an authentication selection screen. The problem with this approach is that it is likely to duplicate user accounts by default. A more robust approach is to ask existing users to sign in with their existing authentication method as part of onboarding to a new one:
Enabling passwordless logins can improve both security and user experience. Yet, this can be difficult for systems with internet users since you must meet two essential requirements. Firstly, you must perform a gradual opt-in migration since you will not be able to update all users at once. Secondly, when existing users log in via passwordless authentication, you will want to avoid creating a duplicate account.
The way to manage these requirements is to first identify existing users without authenticating them, then look up their user account data. For example, suppose a user currently signs in using a password and decides to update their authentication method to a WebAuthn key. In that case, you can ask them to first prove their identity by authenticating with their existing password method. From this point onwards, you can sign the user in very quickly with the new method:
You will need to design a similar flow for users whose email does not exist yet, then run a registration flow. This is also likely to have different behavior depending on which authentication method is used. This highlights an approach for clarifying your authentication requirements. First, identify the various user categories, then sketch out a basic flowchart for each user scenario. Then ensure that your IAM system can meet these requirements.
Satisfying modern authentication requirements for applications is an intricate problem. It is also closely related to data. The best way to plan your next-generation authentication is to start with your requirements, which will include security, usability, and data integrity. When choosing an identity and access management system, verify early on that it can satisfy your criteria.
In the Curity Identity Server, we provide two main building blocks for authentication solutions. These are called authenticators and actions. You can compose them and transform account data via simple scripting. Or, you can implement more intricate behavior using plugins. See the following resources for some real-world behaviors:
Also, make sure to watch out webinar Orchestrating Secure User Login with Authentication Actions available on-demand to take a closer look at authentication actions.