A Passwordless Future: Passkeys for Developers

Deepu Sasidharan

Passwords have been around for thousands of years and we were all happily sharing our Netflix passwords. They are probably not going anywhere but they are not the best way to secure our digital lives. They are a hassle for users and a security risk for applications. The future of secure authentication is passwordless and passkeys are leading the way.

According to Verizon’s 2024 Data Breach Investigations Report, stolen credentials and phishing account for over 65% of all data breaches.

Most of the password problems are human problems as they rely on us humans to remember them and to not share them and do a bunch of other stuff. The main problems with passwords are:

  • Knowledge-based: People can be socially engineered to divulge passwords. If passwords are easy to remember they are also easy to guess. Sharing and reusing passwords makes them even more vulnerable.
  • Phishing & Remote Replay: Phishing websites can easily harvest passwords from even the most tech-savvy. Accounts can be accessed remotely using harvested passwords.
  • Data Breach: Applications become a target for data breaches when they store passwords.
  • Password management: Passwords need password recovery and reset flows and multi-factor authentication flows to secure them further.

Did you know it could cost around 70$ to reset a password?

Of course, password managers help with some aspects of this and everyone should use one. But they are still an overhead and not convenient for everyone, especially non-tech folks.

Passkeys

The obvious solution for the password problem is to go passwordless. This is where passkeys come into the picture.

“Passkeys are a password replacement that provides faster, easier, and more secure sign-ins to websites and apps across a user’s devices. Unlike passwords, passkeys are resistant to phishing, are always strong, and are designed so that there are no shared secrets.”
— FIDO Alliance

A passkey is a unique cryptographic key pair that allows you to access online services without using passwords. It is based on asymmetric public-key cryptography.

Before we dive deep into passkeys let’s look at some of the underlying technologies that make passkeys possible.

Public-key cryptography

Asymmetric public key cryptography involves a pair of mathematically linked keys: a public key, which is shared openly, and a private key, kept secret by the owner.

This key pair can be used for encryption. The same key pair can also be used for digital signatures. A message signed with a private key can be verified with the public key, authenticating the sender’s identity. This is what passkeys use.

Signature verification using Public-key cryptography

Authenticator

An authenticator is a hardware or software entity that can create and store public-private key pairs. There are two types of authenticators:

  • Platform authenticators: It is built into a user’s device. For example, TouchID, smartphone authenticators, Windows Hello, and so on.
  • Roaming authenticators: A removable authenticator usable on any device. They are attached using USB, NFC, and/or Bluetooth. For example, security keys like YubiKey, Google Titan, and smartphones.

FIDO

FIDO stands for Fast IDentity Online. It is a global authentication standard based on public key cryptography developed by the FIDO Alliance.

Passkeys are made possible by the FIDO2 standard which is made up of Web Authentication (WebAuthn) and Client to Authenticator Protocol (CTAP).

Web Authentication

Web Authentication is a W3C recommendation that lets a webpage use a set of JavaScript APIs to talk to authenticators.

WebAuthn architecture

The WebAuthn architecture consists of three main entities:

  • Authenticator: A device that lets a user authenticate by confirming their presence.
  • Relying Party: A server or an Identity Provider (IdP) that requires authentication. It issues challenges and stores public keys.
  • Client: A client consists of the user’s browser. The client relays information between an authenticator and a relying party.

Client to Authenticator Protocol

The FIDO Client to Authenticator Protocol is used for communications with authenticators over a variety of transports like USB, NFC, and Bluetooth. It is used to send requests from WebAuthn to authenticators.

Types of passkeys

Passkeys have two variants. Synced passkeys and device-bound passkeys.

Synced passkeys

Synced passkeys have a better user experience since the private keys are end-to-end encrypted and synced to the cloud. For example, on the Apple ecosystem, the private key is synced on your iCloud Keychain and you can register on one device and log in to any synced Apple device. The same goes for the Google ecosystem using the Chrome browser and Google Password Manager. Synced passkeys can be restored on new devices.

Device-bound passkeys

In the device-bound passkeys, the private key stays on the device itself and you need to authenticate using the same authenticator used for registration. It is slightly less convenient but more secure than synced passkeys. The relying party must support registering multiple credentials for a user as a backup.

How does it work?

Let’s see how user registration and authentication work with passkeys.

User registration

First, let’s see how the registration flow works.

Passkey registration flow
  1. The user begins registration. The relying party provides a randomly generated challenge string.
  2. The navigator.credentials.create() method of the WebAuthn API is invoked and the user provides approval using their authenticator.
  3. The authenticator creates a private-public key pair which is unique for the relying party’s domain and the user. The private key is used to sign the challenge.
    • The private key is stored on the authenticator.
    • For synced passkeys, the private key is also synced to a cloud service for backup and roaming.
    • An attestation object is created which contains the public key, signed challenge, credential ID, and certificate.
  4. The attestation object and other metadata are passed to the relying party by the client-side implementation. The relying party verifies the signed challenge using the public key and registers the user by storing the public key and credential ID along with the user details.

User authentication

Now, let’s see how the login flow works, which is quite similar except for the third step.

Passkey login flow
  1. The user begins the login flow. The relying party provides a randomly generated challenge string.
  2. The navigator.credentials.get() method of the WebAuthn API is invoked and the user provides approval using their authenticator.
  3. The authenticator retrieves the private keys for the relying party’s domain name.
    • For synced passkeys, if the device is new, the private key is synced from a cloud service if available.
    • The user selects the private key for their username. The private key is used to sign the challenge.
    • An assertion object is created which contains the signed challenge and credential ID.
  4. The assertion object and other metadata are passed to the relying party by the client-side implementation. The relying party verifies the signed challenge using the public key stored for the user and authenticates the user.

Why Passkeys?

Passkeys are superior to password + traditional OTP MFA in terms of security and usability and they are as secure and more convenient than password + FIDO MFA. Most importantly, you don’t have to remember anything.

password vs passkeys
  • Discoverable: Passwords are knowledge-based but passkeys are discoverable credentials and the browser can autofill them for a service making it unnecessary for you to remember even usernames. It doesn’t rely on something you know, instead, it relies on something you have or something you are which is more secure from hacking and social engineering. They cannot be reused as they are unique per service and user combination and cannot be shared.
  • Phishing & Remote attack resistant: Passkeys cannot be phished as they rely on public key cryptography and are bound to the domain name of the website, making it impossible to work on a spoofed website. Passkeys rely on physical keys, like biometric sensors of platform authenticators or roaming authenticators like YubiKey, hence cannot be remotely breached.
  • Breach resistant: The website only stores the public key of a user which is useless to an attacker on a data breach on the server side. This makes the server less attractive to hackers.
  • Easier management: Synced passkeys are backed up and replicated across your devices by services like iCloud Keychain and Google Password Manager. This makes recovery part of the platform rather than the application.
  • Cross-device authentication: Passkeys can also perform cross-device authentication regardless of ecosystem or platform. For example, you can simply use your Android phone as an authenticator for your Apple laptop.

Challenges

There are still some challenges when it comes to passkeys:

  • OS/Browser support: It is dependent on the OS and Browser to implement the specs, and we all know how that turns out right? This means the support may not be uniform and can become fragmented. Browser and OS compatibility is still catching up.
  • Cloud vendor reliance: It relies on companies like Apple, Google, and Microsoft to save the private keys in their cloud securely and protect them from breaches.
  • Enterprise use cases: Enterprise users might want more control and flexibility which could be a problem. For example, if an enterprise doesn’t allow iCloud or Google Chrome on their computer, synced passkeys will not work there, only device-bound passkeys will work.
  • Reset & Recovery: There are no default recovery flows for device-bound passkeys, and applications might still need to implement recovery & reset flows to accommodate all use cases.

WebAuthn and Passkeys for Java

Though Web Authentication’s user experience is a client-side implementation using JavaScript, the backend or Relying party can be a Java server. Ideally using an IdP like Auth0 would be the best option since it takes care of all the heavy lifting for you. You can find the sample app using Auth0 on GitHub.

But if you want to implement it yourself and walk the harder path, you can use one of the below libraries.

  • WebAuthn4j: A 100% FIDO2 conformant library with support for all attestation formats and validation. It is used by Keycloak and Spring Security.
  • Java-webauthn-server: A library from Yubico that supports many attestation format. But it is not 100% FIDO2 conformant.

You can find a sample app using WebAuthn4j on GitHub.

Conclusion

Passkeys are the future of secure authentication. They are more secure and more convenient than passwords and traditional MFA. They are also more secure and more convenient than other passwordless methods like magic links, SMS/Email OTP, and push notifications. The wider adoption of passkeys could finally solve the password problem and make the internet a safer place. Learn more on learnpasskeys.io.

Total
0
Shares
Previous Post

Under the Surface: An ‘Iceberg’ Journey through the Lesser-known Faces of Java

Next Post

Cinema, Code, Community: JCON EUROPE 2025 raises the bar for Java events

Related Posts