Designing Your OAuth Login Workflow
Gary Archer
· 4 min readKey Takeaways
Authentication logic has moved out of applications and into IAM systems, using OpenID Connect flows to support multiple sign-in methods centrally.
Account linking is essential — ensuring a user authenticating via different methods (password, social login, passkey) maps to one consistent account, not duplicates.
User accounts can originate in multiple ways: self-registration, admin provisioning, or federation from an external identity provider (auto-created on first login).
Adding new authentication methods to existing users risks creating duplicate accounts unless users first verify their identity via their existing method before linking a new one.
Migrating to passwordless requires a gradual opt-in approach — identifying existing users, having them authenticate with their current method once, then enabling faster sign-in going forward.
Design authentication by first mapping out distinct user scenarios (new user, existing user adding a method, federated user) before implementing flows.
Curity's authenticators and actions provide configurable building blocks for handling these flows, from simple scripting to custom plugins.
On this page
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:
Adaptive Authentication
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.
Conclusion
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 our webinar Orchestrating Secure User Login with Authentication Actions available on-demand for a closer look at authentication actions.
Related resources
Frequently Asked Questions
Can account linking be done automatically without any user interaction?
It's possible in limited cases where a highly trusted matching attribute (like a verified email from a trusted federated IDP) is available, but requiring the user to authenticate with their existing method first is generally safer, since it proves the person requesting the link actually owns both identities.
How does account linking work when a corporate user's Azure AD account is deprovisioned and later recreated?
This typically depends on whether the IAM system matches accounts by a stable internal ID (safer) or by attributes like email (riskier), since a recreated AD account might get a new internal identifier even if the email address stays the same.
Is there a standard protocol for account linking, or is it always custom-built?
There's no single universal standard — account linking is generally considered an implementation pattern rather than a formal specification, meaning IAM vendors (like Curity, with its Account Linking Recipes) provide guidance and tooling, but the specific logic is typically configured per organization's needs.
What's the risk of not implementing account linking correctly?
Beyond duplicate accounts causing business logic issues (like split purchase history or loyalty points), it can create security gaps — for example, if an attacker can register an account with a victim's email before the victim does, improper linking could enable account takeover.