fix(auth): use direct attestation for registration/authentication

[mandarini]

Moved from: supabase/auth-js#1126
Author: @Bewinxed

What kind of change does this PR introduce?

Fix/Enhancement

What is the current behavior?

The WebAuthn implementation currently sets attestation: 'none' in the default creation options, which means the authenticator doesn't provide any attestation statement during registration.
As per Yubico's Recommendation, this should be set to direct to allow us access to the make/model/version of the security keys being used. More Info

• Whether the authenticator is genuine (not a software emulator)
• The authenticator's make/model/manufacturer
• Whether it meets security requirements for the application

What is the new behavior?

Changed attestation from 'none' to 'direct' in DEFAULT_CREATION_OPTIONS.

Additional context

With attestation: 'direct', the server can Verify authenticator make/model and possibly reject unknown models using the AAGUID of the security key.

[issuedat]

Thanks for the PR @Bewinxed! This change makes sense to me — would you be able to confirm:

1. Will this be handled gracefully on devices that had some issues with direct? I recall seeing that older versions of Safari would fallback to sending an attestation of type none and zeroed-out GUIDs.
2. Would we be introducing any breaking changes moving to a stricter type? I would imagine there wouldn't be any issues since the enforcement would have to happen on the backend

[Bewinxed]

Thanks for the PR @Bewinxed! This change makes sense to me — would you be able to confirm:

1. Will this be handled gracefully on devices that had some issues with direct? I recall seeing that older versions of Safari would fallback to sending an attestation of type none and zeroed-out GUIDs.
2. Would we be introducing any breaking changes moving to a stricter type? I would imagine there wouldn't be any issues since the enforcement would have to happen on the backend

Thank you!

1 - According to the spec, attestation will be none when the provided param is incompatible with the current browser/environment, this should just set aaguid to "none" and this is set only in the default config, the original PR added support for yubikey but it also adds webauthn as a whole, so if the developer expects browsers/users who are on safari/older browsers, they can use any kind of attestation they want via the overrides in the authjs client.

2 - this only changes what data is requested from the authenticator (not what's required), existing flows continue to work;

• Clients that can provide attestation will send it
• Clients that can't will send "none"
• The backend can choose to use or ignore the attestation data
• Current implementations that don't check attestation won't be affected at all.

also since this PR was added together with the webauthn PR, there shouldn't be anything to break.

[issuedat]

Thanks for confirming and the speedy clarification @Bewinxed! 😊