OAuth, OIDC, WebAuthn, SAML, tokens, and other jargon from the security world primarily revolve around a few philosophies. Usernames and passwords should be sent as rarely as possible, just use tokens if both parties in a transaction can be proven to be authentic, and guard the rights to access pieces of information about an account (metadata) against unauthorized access. Most of these have been around for 15 to 20 years; yet we still need to enter our information into websites routinely.
This means we still use passwords. Passwords give us access to the passwordless future of passkeys. They also still get us into the 99% of sites that don't support Passkeys. Passwords also act as a backup to Passkeys when they aren't accepted on sites we have a Passkey to access. For example, if we use Google then while the Passkey authenticates use for many operations, our account page and email client may still prompt for a password.
The world has been marching towards a new, "passwordless" future for a long time. In fact, many of the technologies on that path are over 20 years old at this point, including:
Passwords: 1961
LDAP: 1993
JSON: 2001
SAML: 2002
OpenID: 2005
JWT: 2010
Apple's Secure Enclave: 2013
OIDC: 2014
TPMv2: 2016
WebAuthn: 2016
Each of these built on the previous technology to put new options in our hands as phones and laptops became our primary form of digital communication. Now, the primary way most think of a good password paradigm in companies is to use a federated identity manager, like Okta, Azure AD, etc and to use a password manager on local computers. When built with a little deeper thinking about how humans interact with technology, they can work in harmony and allow users to access resources, quickly provision or take away access to resources, and even share credentials as needed, with the exception of Passkeys.
Passkeys are inherently user-centric. They build on WebAuthn by taking into account the TPM chips (or Secure Enclave in Apple parlance) now built into most computing devices. For example, simply FaceID or TouchID to unlock a password in Apple's Keychain app. This is also true for tokens, which are harder to share programmatically, but follow a similar design pattern. Passkeys on the other hand are issued per user, per device. This means there aren't many use cases where it's appropriate to share them. This is why Secret Chest supports Passkeys up to the point where we enable credential sharing. We allow users to share passwords but not Passkeys.
The developers of WebAuthn did allow Passkeys to be "shared" between devices, but gave no guidance for flows around sharing them between users. It's clear in the minutes of their meetings that they in fact weren't too hot on allowing Passkeys to be shared between users. Once there's a standard for making it possible to share Passkeys, we'll quickly build that into the product. In the meantime, it's a small step with the few vendors that have developed Passkey support to issue new ones that Secret Chest can help store in an appropriate manner.
Comments