Some while back, I proposed that the use of passwords for authentication is part of a vintage workflow. We should stop using them as soon as we can.
But we cannot. The decision about this is distributed over an army of developers across an ocean of content and service providers in an ever expanding cloud. If you work and play in today’s world, you almost certainly have many dozens of passwords.
Or just ONE!
And if that’s your solution, then you’ve chosen an approach that’s actually slightly better than not having passwords at all. But just barely.
Let’s take a look at the alternatives from the perspective of a system designer who needs to add authentication to their service.
Your Choices
Here are some of the methods used to ensure that you are who you say you are.
Passwords – We all know and hate this approach. Most of us have far too many passwords, or we capitulate to necessity and use the same one everywhere. Or we record them where they can be compromised. They are still a necessary evil as a consumer, and a choice to be shunned as a system designer.
Passphrase – This is a secret issued by the platform. It is equivalent to the long established security mechanism known as a “day code” translated into modern IT operations. The accessed platform supplies a value with a carefully limited lifespan. This is excellent for temporary and limited access to a system. If a platform designer takes this approach, it’s best to wrap it in a workflow that delivers the passphrase seamlessly to the client application. (For instance, a system might send the phrase through email or text to the user, or simply embed it in the requesting application.)
Use an IDP – A platform designer might choose this to leverage OIDC (OpenID Connect) or SAML. That might include connections to Google, Microsoft, Facebook, or Salesforce, for instance. At the time of authentication, a request is sent to the IdP where the identity is validated.
With this approach, the platform delegates the grunt work of user profile management to the provider. For that reason alone, this is already the best general purpose approach to authenticating users. But it gets better. When using this approach, the IdP in addition to presenting a simple pass/fail indication, can also deliver data about the user when requested and approved. One important example might be a list of Scopes (permissions to operate within a given domain), or other authority derived from a profile.
Secret Key – This could be one of the most robust of security measures for authenticating identity and granting authority. In this case, the platform provides a cryptographic key (like an SSH key, or a digital certificate) and the user stores it on the device that will access the service.
In spite of the increased administrative overhead and the skills needed to properly maintain a secret key, its use is still highly useful in two scenarios.
First, if it will be necessary to authenticate an autonomous “user,” (such as an API or application that calls your service,) this is the best approach. Having other programs call your service is often needed, and of course we would like to constrain authority to the set of allowable actions.
Second, when using an IdP, it is possible for the end user to inadvertently disconnect access and be locked out. So designing a recovery procedure that allows users to unlock their account in such cases is an important step in the development process.
Summary
There’s no “right” choice for designers. It seems that in today’s world, using IdP connections to validate users, along with a system for Secret Keys to support autonomous logins and account recovery, is a solid approach.