Both nextAuth and FIDO aim to provide more secure and user-friendly user authentication. However, there are some differences in the approach. While nextAuth offers login, signing and secure sessions; FIDO only offers login functionality.
What is FIDO?
FIDO is an alliance of Internet Services, Component & Device Vendors, and Software Stacks. This alliance developed several open user authentication standards:
- Universal Authentication Framework (UAF) to provide a password-less experience.
- Universal Second Factor (U2F) to provide the second factor experience.
- FIDO 2:
- W3C’s Web Authentication specification (WebAuthn), FIDO authentication webAPI integrated into browsers.
- Client To Authenticator Protocol (CTAP), a device to device local protocol.
For the technical details on nextAuth, have a look at our technology page.
What are the similarities?
Both nextAuth and FIDO use public key cryptography. In the public key setting, there is a private key with corresponding public key. The party with the private key can authenticate to any party with the public key. The private key never leaves the nextAuth mobile component (FIDO authenticator). The public key is stored at the nextAuth server component (FIDO relying party). Social engineering to trick users into sharing their credentials will not work, since users don’t know these. The server also becomes less vulnerable to attacks. This is because it contains only public keys, which in itself cannot be used to authenticate with.
Both nextAuth and FIDO value the user’s privacy. To prevent tracking across servers, nextAuth and FIDO both generate new keys for each server.
How is nextAuth different?
nextAuth provides mutual authentication between the server component and the mobile component. Furthermore, authentication is a continuous state. Both components can thus stop the authenticated session. This gives users a great deal of control over their sessions. Users might still get tricked into authenticating a session that is not theirs. But they can immediately log out if they notice. This gives the attacker only a very limited window of opportunity.
Conclusion
| nextAuth | FIDO | |
|---|---|---|
Functionality | ||
Login | ||
Signing (e.g., transactions, documents) | ||
Secure sessions (logout) | ||
Resistant against attacks vectors | ||
Social engineering | ||
Local (authenticator) | ||
Remote (server) | ||
Man-in-the-middle | ||
User | ||
User unlinkability (privacy) | ||
User in control over session | ||
No configuration by user | ||
* In terms of authenticating the relying party, FIDO relies solely on the webbrowser/app to verify the TLS connection. Also note that while apps can (and should) implement certificate pinning, webbrowsers cannot.
** Biometrics are checked locally by the device the nextAuth mobile component is running on. If successful, a cryptographic key is unlocked. This key will then be verified with the nextAuth server component in a zero-knowledge fashion.
