nextAuth vs. FIDO

Both nextAuth and FIDO aim to provide more secure and user-friendly user authentication. However, there are some differences in the approach.

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.

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.

 

 

FIDO only provides authentication from the authenticator to the relying party*. This unilateral authentication makes FIDO vulnerable to Man In The Middle attacks. Furthermore, FIDO considers authentication still as an event instead of a state. Once you provide a valid signature on the given challenge, you are in.

When it comes to verifying the user, the nextAuth mobile component verifies the second factor (PIN or biometric**) online, with the help of the server. nextAuth does this in a zero-knowledge fashion, whereby the server does not learn anything about the PIN or biometric. This approach excludes both local and remote attacks. In FIDO, user verification is done offline/locally by the FIDO authenticator, leaving it vulnerable to local attacks.

With nextAuth you can log in with your nextAuth mobile component on any webbrowser on any device, without having to configure this device. The device with the webbrowser/app that requests FIDO authentication needs to be running a FIDO authenticator; or be connected to one over either USB, Bluetooth LTE or NFC. In other words, one cannot simply use his/her authenticator with any device without having to configure this device, insert a USB device, do a Bluetooth pairing, and/or switch on NFC. Furthermore, while most modern platforms and webbrowsers support the FIDO standard, this is still not generally true.

Conclusion

* 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.