Email Verification Not Reflected in Identities Table (and JWT)

[janekwunderlich]

Bug report

• I confirm this is a bug with Supabase, not with my own application.
• I confirm I have searched the Docs, GitHub Discussions, and Discord.

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]

@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]

@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.