[GH-ISSUE #978] Registered Passkeys not found #8530

Closed
opened 2026-04-13 03:37:53 -05:00 by GiteaMirror · 1 comment
Owner

Originally created by @masterjanic on GitHub (Dec 21, 2024).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/978

Is this suited for github?

  • Yes, this is suited for github

To Reproduce

  1. Create a project with the passkey plugin and database schema
  2. Register a new passkey
  3. Try to sign in with newly registered passkey

Current vs. Expected behavior

When trying to sign in with a passkey it should be found via the id (primary key) field. Currently these values are stored correctly, but the /passkey/verify-authentication does not correctly query the passkey.

image

^ credentialID field is returned as id in response (wrong)

image

What version of Better Auth are you using?

1.1.1

Provide environment information

/

Which area(s) are affected? (Select all that apply)

Backend, Client

Auth config (if applicable)

import { betterAuth } from "better-auth"
export const auth = betterAuth({
  emailAndPassword: {  
    enabled: true
  },
  plugins: [
    passkey({
      rpID: "localhost",
      rpName: "localhost",
      origin: "http://localhost:3000",
    }),
  ],
});

Additional context

I have tested that passkey registration and deletion work correctly using the primary key as id field.

The cause of the issue is 809f63f8e2/packages/better-auth/src/plugins/passkey/index.ts (L641-L654)

Follow up of: #865

Since the response body has a z.any() schema the issues became undetectable. The schema should be improved to match the correct response.

Possible quick fix: query credentialID from database adapter instead of id field (not recommended, because probably not indexed)

Recommended solution: Endpoint should return correct primary key field instead of credentialID as id so that the database query will resolve correctly.

Originally created by @masterjanic on GitHub (Dec 21, 2024). Original GitHub issue: https://github.com/better-auth/better-auth/issues/978 ### Is this suited for github? - [X] Yes, this is suited for github ### To Reproduce 1. Create a project with the passkey plugin and database schema 2. Register a new passkey 3. Try to sign in with newly registered passkey ### Current vs. Expected behavior When trying to sign in with a passkey it should be found via the id (primary key) field. Currently these values are stored correctly, but the `/passkey/verify-authentication` does not correctly query the passkey. ![image](https://github.com/user-attachments/assets/602cc0ef-a46a-46e6-8ee7-892509a122ac) ^ `credentialID` field is returned as `id` in response (wrong) ![image](https://github.com/user-attachments/assets/82ed3937-1d9e-4714-b5bc-2ad79f193f38) ### What version of Better Auth are you using? 1.1.1 ### Provide environment information ```bash / ``` ### Which area(s) are affected? (Select all that apply) Backend, Client ### Auth config (if applicable) ```typescript import { betterAuth } from "better-auth" export const auth = betterAuth({ emailAndPassword: { enabled: true }, plugins: [ passkey({ rpID: "localhost", rpName: "localhost", origin: "http://localhost:3000", }), ], }); ``` ### Additional context I have tested that passkey registration and deletion work correctly using the primary key as id field. The cause of the issue is https://github.com/better-auth/better-auth/blob/809f63f8e2851da44c773a666a4f87202125640a/packages/better-auth/src/plugins/passkey/index.ts#L641-L654 Follow up of: #865 Since the response body has a `z.any()` schema the issues became undetectable. The schema should be improved to match the correct response. Possible quick fix: query `credentialID` from database adapter instead of `id` field (not recommended, because probably not indexed) Recommended solution: Endpoint should return correct primary key field instead of credentialID as id so that the database query will resolve correctly.
GiteaMirror added the lockedbug labels 2026-04-13 03:37:53 -05:00
Author
Owner

@Bekacru commented on GitHub (Dec 21, 2024):

We can only use credentialID because, initially, we can't know the user's passkey ID to authenticate

<!-- gh-comment-id:2558074976 --> @Bekacru commented on GitHub (Dec 21, 2024): We can only use `credentialID` because, initially, we can't know the user's passkey ID to authenticate
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#8530