feat: add endpoints - authenticate [passkeys] #4
Conversation
matteyu
changed the title
matteyu
changed the title
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
matteyu
changed the base branch from
development
to
arc-1133/row-level-security
matteyu
changed the base branch from
arc-1133/row-level-security
to
development
|
Updated video of iframe test with passkeys https://drive.google.com/file/d/1Imw5hxeI34aJm408QKV0xbAtLE_bUFpz/view?usp=drive_link Draft PR updated to support passkeys in iframe: wanderwallet/Wander#793 |
| } | ||
|
|
||
| // Fetch the user from the database | ||
| const userProfile = await prisma.userProfile.findUnique({ |
There was a problem hiding this comment.
Auth tokens can never be generated on the client, as this allows an attacker to steal anyone else's session/account.
There was a problem hiding this comment.
The token gets generated on the server and get sent to the client so the signing key is still on the server. It just gets stored in localstorage on client side and sent back upon requests to the server
server/context.ts
Outdated
|
|
||
| // If session doesn't exist, create it based on the token data | ||
| const newSessionId = decodedToken.session_id || crypto.randomUUID(); | ||
| const newDeviceNonce = decodedToken.device_nonce || deviceNonce || crypto.randomUUID(); |
There was a problem hiding this comment.
Device nonces should also be generated on the client.
There was a problem hiding this comment.
removed crypto.randomUUID(); for server generation
server/utils/passkey/session.ts
Outdated
| email: string | null; | ||
| phone: string | null; | ||
| app_metadata: { | ||
| sessionData?: { |
There was a problem hiding this comment.
Session data seems to be at the root, not nested inside app_metadata. app_metadata could be used to identify this sessions as originating from a passkeys authentication, as it usually contains something like this:
"app_metadata": {
"provider": "twitter",
"providers": [
"twitter"
]
}
However, if you fetch a session on the client, you'll session.user also contains an identities property. I'm not sure if manually setting the value of provider and providers will throw any error, as it's related to this: https://supabase.com/docs/guides/auth/auth-identity-linking
If that doesn't work, I guess it would make sense to set app_metadata.provider to the value that corresponds to email and password, as that's how we created those users anyway, and move the user details to user_metadata. This means that the client should not need to store any kind of data to know whether a session comes from a passkeys authentication or something else, as the session itself contains that information.
There was a problem hiding this comment.
good point. I restructured it so that it specifies passkey auth method in app data. I've tested it and it did not throw any errors when manually setting these values.
JIra: https://communitylabs.atlassian.net/browse/ARC-937?atlOrigin=eyJpIjoiNGFhMGUwZTE0ZTc2NDIyNmJmYmE5NGRkZjhiNDUzYWQiLCJwIjoiaiJ9
Passkeys auth implementation
Screen.Recording.2025-03-23.at.9.07.46.PM.mp4