search

supabase / auth

A JWT based API for managing users and issuing JWT tokens
https://supabase.com/docs/guides/auth
MIT License
1.42k stars 345 forks source link

Email Verification Not Reflected in Identities Table (and JWT) #1620

Open janekwunderlich opened 3 months ago

janekwunderlich commented 3 months ago

Bug report

Describe the bug

When a user clicks on the email authentication link (causes a GET /verify request), the email_confirmed_at field gets updated in the users table and the one-time token gets cleared, but the email_verified field does not get changed to true in the identities table (and hence is not properly shown in the JWT).

To Reproduce

Steps to reproduce the behavior, please provide code snippets or a repository:

  1. Go to 'Click on email authentication link'

  2. Observe the GET /verify request

  3. Check the users table and note that the email_confirmed_at field is updated and the one-time token is cleared.

  4. Check the identities table and note that the email_verified field is not updated to true. JWT does not reflect the email_verified status.

I was able to reproduce this on Supabase and on a self-hosted instance.

Expected behavior

The email_verified field in the identities table should be updated to true when the email is confirmed, and this should be properly reflected in the JWT.

Additional context

The ResourceServer cannot properly verify whether a users email address has been verified.

kangmingtay commented 1 month ago

@janekwunderlich is it possible to use the email_confirmed_at field instead? the email_verified field actually refers to the verification status of the email associated to the identity, so it depends on what the provider returns us (in the case of oauth)

but yeah, in the case or magiclinks you mentioned, this should be in-sync with the email_confirmed_at column

janekwunderlich commented 1 month ago

@janekwunderlich is it possible to use the email_confirmed_at field instead? the email_verified field actually refers to the verification status of the email associated to the identity, so it depends on what the provider returns us (in the case of oauth)

but yeah, in the case or magiclinks you mentioned, this should be in-sync with the email_confirmed_at column

If you are referring to the email_confirmed_at field that is returned outside of the JWT token's access_token field, that is an unverifiable claim to whatever resource the user is trying to access.