feat(webauthn): Extend authenticator model to store AAGUID and origin

[kyb3r]

☕️ Reasoning

I've extended the Authenticator type to include two new fields:

• credentialAAGUID - This is used to identify the type of authenticator that was registered, this would mostly just help with displaying a name for authenticators in application UI for users. See: https://github.com/passkeydeveloper/passkey-authenticator-aaguids
• credentialOrigin - The origin of the website that the authenticator was registered at. This would be useful for keeping track of authenticators that were registered in different environments (e.g. localhost, preview, production) as they all have different origins.

🧢 Checklist

• Documentation
• Tests
• Ready to be merged

🎫 Affected issues

📌 Resources

• Security guidelines
• Contributing guidelines
• Code of conduct
• Contributing to Open Source

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
auth-docs	❌ Failed (Inspect)			Apr 8, 2024 9:51pm

1 Ignored Deployment

Name	Status	Preview	Comments	Updated (UTC)
next-auth-docs	⬜️ Ignored (Inspect)	Visit Preview		Apr 8, 2024 9:51pm

[vercel]

@kyb3r is attempting to deploy a commit to the authjs Team on Vercel.

A member of the Team first needs to authorize it.

[ndom91]

Awesome addition of the AAGUID, this will make buildling UI around the passkeys providver much nicer.

Regarding the credentialsOrigin though, wouldn't that always just always be the origin of the user's application? Like the app the user is using auth.js with?

[kyb3r]

Regarding the origin, especially in the case of developing locally and having a preview deployment up, you can’t reuse passkeys across origins.

So the same passkey won’t work across preview/development using the same database. So to do testing you have to register a seperate passkey for each origin you are testing on.

Storing the origin associated with the authenticator would simply make it easier to keep track of your different passkeys in the ui.

But at the same time this wouldn’t be difficult for users to implement as a custom adapter method in createAuthenticator by just checking which env and relaying party you are using currently.

What are your thoughts? @ndom91

[kyb3r]

Without this PR, this is how I'm currently getting the same functionality. It's kind of wacky but the end result is worth it :)

In my custom adapter I can inject values into the Authenticator table

All of this lets us show some good guesses for what the authenticator may be in the ui:

I really hope the way I implemented this is not stupid lol, if an easier way flew over my head let me know haha

[ndom91]

Hmm okay I get what you're getting at with the origin field I think. However, I'd wager that most people also have separate databases for their dev / prod instances (or at least I'd hope so 😅). So I'm not totally convinced that we need that field.

What are you using it for in your use-case exactly? Just to tell the difference between staging / dev / prod passkeys as you're sharing a DB between the different environments?

[kyb3r]

Hmm okay I get what you're getting at with the origin field I think. However, I'd wager that most people also have separate databases for their dev / prod instances (or at least I'd hope so 😅). So I'm not totally convinced that we need that field.

What are you using it for in your use-case exactly? Just to tell the difference between staging / dev / prod passkeys as you're sharing a DB between the different environments?

Yes i’m sharing a database between environments.

Yeah I totally get it, I can remove the origin field if needed. But the AAGUID field is pretty useful i’d say.

[ndom91]

@kyb3r okay awesome, yeah let's do that then. AAGUID only, no origin 👍

[kyb3r]

@ndom91 Done

[kyb3r]

Any updates?