The Role Of Passwords In A CIAM System
Heya,
Passwords are an old form of authentication, but unfortunately there are two major issues with passwords.
it's hard for humans to remember good ones
it's easy for attackers to guess bad ones
Unauthorized access to an application is bad. So when should you allow passwords to be used to authenticate into your application? And what requirements, if any, should you have about the password presentation process?
If you can avoid passwords, do
Nowadays there are better, more secure, friendlier options available for customers to log into systems than passwords. These include:
federation
possession
passkeys
If you can use one of the above, you should. However, these may not work for your users.
Remember, the first rule of CIAM is your customers are paying you, which means your authentication mechanism needs to meet their needs as well as yours.
Let's look at each of these options and examine why they might not work.
Federation
Federation is when your application delegates authentication to another identity system. This might be a social provider like Google, Facebook, or WeChat. Or it might be a more specialized identity store like Xing (for European business users), Steam (for games) or GitHub (for developers).
Either way, your application sends the user to the remote system for authentication. Then your app gets a thumbs up or thumbs down from the source of identity, as well as some information about the user. You can store the data in your system and grant access based on the result.
There are some reasons you might not want to offer this option:
Users might not have an accessible account at one of the federation options.
Users might not trust federation, even if they do have an account. Some people are worried about linking too many accounts to Google because they could lose access to that account (examples) and to all the accounts tied to it.
Users might trust the federated identity provider, but not trust you. They might not want you to have the link between a trusted identity and their data in your system.
There may be information that the identity provider doesn't reliably provide. For instance, GitHub doesn't provide an email address on successful federation unless the user has a public email address. You may need an email address for your application's functionality.
You may need more assurances than the federated provider can provide around authentication, including failed attempts. You may work around this to some extent by implementing MFA after a successful federation.
Availability requirements may dictate that you can't afford to rely on the providers being available .
When you delegate to the federated identity provider, they control the login flow, including validation and error messages. That may not be acceptable.
If federation doesn't work, how about magic links or one time codes, which rely on the user posessing access to an inbox or phone number?
Possession
With magic links or a one time code authentication process, the CIAM system sends a message to user, who has a deliverable identity. The possession of the message, usually indicated by the user providing a time bound random code, proves the user's identity.
There are a few reasons why this might not work for your users:
They may not have a deliverable identity. The most common types of deliverable identities for customers are an email address or a phone number. If your userbase is children, they may have neither.
A user may lose access to an email address or a phone number, especially if they seldom visit your application.
Message delivery takes time. While SMSes and emails typically are delivered quickly, they are not always. This delay impacts your user's experience.
Similarly, message delivery is not 100% reliable. You can work around that with retries requested by the end user.
Magic links can be invalidated by link checkers, but your application will be blamed.
Message delivery options can be less secure. For instance, SMS is vulnerable to social engineering attacks and email accounts are vulnerable to phishing.
The user may not want to share a deliverable identity for fear of future abuse.
The delivery identity may be accessed on a different device than the user initiated the authentication on. For example, I may try to log in on my laptop, but the email address I use may only be accessible on my phone. This is a hassle, degrading the user experience.
SMSes, a common message delivery choice, costs money, especially at scale.
If one time codes and magic links are problematic, how about passkeys? Aren't they the greatest thing since sliced bread?
Passkeys
Passkeys, which use cryptographic signatures and public private key cryptography to offer phishing resistant, widely accessible authentication might seem like the perfect CIAM authentication solution.
However, there may be issues:
Passkeys are still not widely supported by websites (only 175 listed here), so they may be confusing to your userbase.
While passkeys are supported by most major browsers, some users may not offer a seamless user experience.
Passkeys are either tied to a single device, which is confusing to the end user, or they are synced via an entity like Google or Apple, in which case users may have some of the same concerns as they do with federation.
If you allow passkeys, you won't get any identity information about the user. You can, of course, collect it before they proceed further in your application.
There are no recovery mechanisms in your control.
The UX customization for the passkey registration and authentication flows is extremely limited.
Surprise surprise, passkeys have issues too. What to do?
Back to passwords
First, offer options to your customers. Maybe the folks who don't have a Google account will be okay sharing an email address, and maybe the folks who want to use a passkey are technically comfortable enough not to be confused by the login process.
That is one nice thing about authentication; you can offer multiple paths into your application. But you may review your options decide that you want to support passwords, the lowest common denominator for online authentication.
If so, follow the NIST guidelines for memorized secrets, AKA passwords. Have a minimum length and check for compromised passwords.
The linked version is v3. V4 is still in the works, but you can follow along here.
Then, once you have met the NIST guidelines, further tweak them based on your needs.
These folks did, because they felt that a higher minimum length made sense based on the senstivity of the data they hold, as well as the type of user who is interacting with a secrets management system.
Finally enable MFA. This prevents many attacks, even in 2024.
Know your customers
There are a lot of 'may's and 'possibly's above. How can you really know what your users need for authentication methods?
Start with your intuition about your customer base. It's not absurd to believe that more developers will understand passkeys and more middle-aged folks will have Facebook accounts. The same way you know what features your users want because you understand them, you can know how they want to authenticate.
Second, ask them. Ask them directly, through customer interviews and user studies, or indirectly by enabling additional methods and seeing if customers user them. Using an auth server or a library which easily enables these methods can allow for low effort testing.
Finally, don’t forget to understand what your business needs. Verified email addresses are a lot easier to gather if you are using magic links/OTP than if you are using passkyes, for example.
Mesh the needs of the application around user data with what your users want and expect.
Hope this helps you pick the right path for your CIAM system credentials.
Dan