Over the last few posts we have discussed how to store passwords on the db, how to protect our users via MFA, how to log them in via SAML and SSO and more.
But all of these have one thing in common: Our users still need to have password stored somewhere. The question is where.
Let’s take John as an example.
John has 5 SaaS applications he is using regularly.
If he relies on SSO, that’s easy. He has only one password to remember (his IDP / OAuth password). But what happens if he doesn’t use SSO?
Like many people, John will probably create a password for each of his 5 SaaS applications thereby exposing his account in the event that any one of them is breached.
And furthermore, what if John can’t keep track of which password goes where? Then what?? Will he just decide to use an identical password for every single one of his accounts thereby creating greater vulnerability should even one of his accounts be breached.
What are passwordless logins?
Passwordless authentication usually requires the user to actually provide some kind of proof that he is really the user he claims to be, without providing the password as part of the authentication flow.
This may sound complex but actually it isn’t.
Let’s take this flow:
We’ve all experienced it without actually thinking about the fact that we are running through a passwordless login flow.
The proof for the authenticity of the user, in this case, is the “ownership” over the email box and being able to prove the ownership via the control over the OTP code which was sent via the verification email.
But is email the only method for password-less logins?
Well no, it actually isn’t. There are a few other methods we can turn to.
For one thing, we can rely on the use of “ownership methods” in order to provide validation such as phone numbers, dongle keys, HW tokens, and more. Whereby the second method will be the user of “Inherence methods” such as fingerprints, face recognition etc.
So far all of this is sounding quite familiar, right?
We did mention OTP and “Device ownership” and it sounds as if this is another method of MFA? Well, in most cases MFA is required as another level of security for password-based logins. When we provide password-less-based authentication, we can “spare” this part and log in the user directly as soon as he has proved his ownership.
So, does this mean that you should quickly run tomorrow morning to delete ALL passwords from your DB and solely provide password-less based authentication?
Let’s wait a bit before running to delete them all and first consider the pros and cons for password-less vs. password-based authentication.
The pros to using password-less authentication are rather obvious:
- Hardening security – passwords are always weak. This is true on each and every SaaS application. Human nature drives the users to maintain the same password across all SaaS applications which leads to an increased risk of password breach.
- UX – Users do not need to remember passwords, change them every X days and follow strict password policy rules when changing passwords since password-less offers easy flow via email.
The cons of the password-less approach are, among other things:
- Hard to implement – In most cases, email + passwords are very easy to implement but a flow where we would need to maintain expirations on tokens and shipping out emails, makes the implementation complex and increases development costs.
- Still not a standard – While the users are used to email and password-based authentication, the “entry point” for password-less authentication is somehow limited.
- The dependency of 3rd parties – Using password+email-based authentication means we can take care of activation immediately. When one of the users is not getting his activation email, the dependence makes it harder to integrate.
- Less relevant in the case of IDP / SSO based authentication.
When our users log in via SAML and SSO authentication, there is no need for password-less authentication (at least on the SaaS application side). The user has one password for the entire span of their SaaS operations and this is the same password which is used for his email login.
Password-less logins are here to stay. This idea of not requiring a user to remember any passwords to the multiple accounts they are using enhances the level of trust in the authentication flow.
At Frontegg we took all of these requirements into consideration when building our SaaS as a Service platform. If you have any questions as to what the correct model is for you and how you should implement them then feel free to reach out. We are here to help.