FIDO (Fast IDentity Online) authentication is a set of standards for fast, simple, strong authentication.
These standards are developed by the FIDO Alliance, an industry association with representatives from a range of organizations including Google, Microsoft, Mozilla, and Yubico. The standards enable phishing-resistant, passwordless, and multi-factor authentication. They improve online UX by making strong authentication easier to implement and use.
Some of the web's most popular tools and apps are already using FIDO authentication, including Google Accounts, Dropbox, GitHub, Twitter, and Yahoo Japan.
Users win. Users benefit from authentication flows that are fast and secure.
Developers win. App and web developers can use simple APIs to securely authenticate users.
Businesses win. Site owners and service providers can more effectively protect their users.
How does FIDO authentication work?
In a FIDO authentication flow, a relying party uses APIs to interact with a user's authenticator.
The relying party is your service, composed of a back-end server and a front-end application.
This involves passing a cryptographic challenge from the server to the authenticator, and returning the authenticator's response to the server for validation.
The server stores the user's public key credential and account information.
During an authentication or registration flow, the server generates a cryptographic challenge in response to a request from the application. It then evaluates the response to the challenge.
A FIDO authenticator generates user credentials. A user credential has both a public and a private key component. The public key is shared with your service, while the private key is kept secret by the authenticator.
An authenticator can be part of the user's device, or an external piece of hardware or software.
The authenticator is used in two basic interactions: registration and authentication.
In a registration scenario, when a user is signing up for an account on a website, the authenticator generates a new key pair that can only be used on your service. The public key and an identifier for the credential will be stored with the server.
In an authentication scenario, when a user returns to the service on a new device, or after their session expires, the authenticator must provide proof of the user's private key. It does this by responding to a cryptographic challenge issued by the server.
To verify the identity of the user, some types of authenticator use biometrics such as fingerprints or facial recognition. Others use a PIN. In some cases, a password is used to verify the user and the authenticator provides only second-factor authentication.
Take a codelab:
Learn more about: