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)			May 28, 2024 3:16pm

1 Ignored Deployment

Name	Status	Preview	Comments	Updated (UTC)
next-auth-docs	⬜️ Ignored (Inspect)	Visit Preview		May 28, 2024 3:16pm

[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?

[ndom91]

We've updated the WebAuthn adapter schema since the opening of this PR.

1. The Authenciator table no longer has an extra id primary key field.
2. It's ID is a composite field based on userId + credentialID.

See for example: packages/adapter-prisma/prisma/schema.prisma:54

model Authenticator {
  credentialID         String  @unique
  userId               String
  providerAccountId    String
  credentialPublicKey  String
  counter              Int
  credentialDeviceType String
  credentialBackedUp   Boolean
  transports           String?

  user User @relation(fields: [userId], references: [id], onDelete: Cascade)

  @@id([userId, credentialID])
}

Could you update your schema and include the new field in the migrations / example schemas for (1) Unstorage and (2) Drizzle adapters? They've also recently gained WebAuthn support.

They have schemas / migrations potentially in their code files (/packages/adapter-unstorage/*) but also potentially in their docs page (/docs/pages/getting-started/adapters/unstorage.mdx).

I'd appreciate if you cuold check all that and then we can get this merged! 🙏

[ndom91]

There's multiple adapters which support webauthn now. Can we update their schemas where necessary as well in this PR?

There's their docs pages and potentially the packages/adapter-*/ directories where they may have schemas for tests, seeding, etc.

The adapters are:

• Prisma (packages/adapter-prisma/,docs/pages/getting-started/adapters/prisma.mdx)
• Drizzle (packages/adapter-drizzle/,docs/pages/getting-started/adapters/drizzle.mdx)
• Unstorage (packages/adapter-unstorage/,docs/pages/getting-started/adapters/unstorage.mdx)

[kyb3r]

Gonna be honest, I don't really have the time to do this unfortunately. I think it will be faster to take over since the changes are very minimal.

[ndom91]

Gonna be honest, I don't really have the time to do this unfortunately. I think it will be faster to take over since the changes are very minimal.

Yeah no worries, thanks for getting back to us