Refactor user schema to store provider data better

[kangmingtay]

What kind of change does this PR introduce?

• All OAuth providers should return the provider id which is unique to a user (regardless of whether the user changes the email associated with the provider login, the provider id will remain the same)
• Use provider id as primary identifier instead of email for external oauth flows
• Create identities table to each identity associated with a user
• raw_app_meta_data.provider field will be marked as deprecated
• Return identities in access token payload in the following format:

{
  "aud": "authenticated",
  "exp": 1632719084,
  "sub": "12345",
  "email": "a@a.com",
  "phone": "",
  "app_metadata": {
    "provider": "google"
  },
  "user_metadata": {
    ...
  },
  "identities": [
    {
      "id": "1",
      "user_id": "12345",
      "identity_data": {
        "avatar_url": "",
        "email": "a@a.com",
        "email_verified": true,
        "full_name": "a",
        "iss": "https://www.googleapis.com/userinfo/v2/me",
        "name": "abc",
        "picture": "",
        "provider_id": "1",
        "sub": "1"
      },
      "provider": "google",
      "last_sign_in_at": "2021-09-27T10:13:48.877604+08:00",
      "created_at": "2021-09-27T10:13:48.877648+08:00",
      "updated_at": "2021-09-27T10:13:48.877652+08:00"
    },
    {
      "id": "123",
      "user_id": "12345",
      "identity_data": {
        "email": "a@a.com",
        "email_verified": true,
        "iss": "https://appleid.apple.com/auth/keys",
        "provider_id": "123",
        "sub": "123"
      },
      "provider": "apple",
      "last_sign_in_at": "2021-09-27T12:04:43.376864+08:00",
      "created_at": "2021-09-27T12:04:43.37691+08:00",
      "updated_at": "2021-09-27T12:04:43.376916+08:00"
    }
  ],
  "role": "authenticated"
}

[sandbox-apps]

I just want to fix this sentence.

• Use provider id and provider name (e.g. google, facebook, twitter) as primary identifier instead of email for external oauth flows

[sandbox-apps]

Just for clarification. what will happen for those auth that have been registered before this fix? Does those auth account already have the provider id and provider name in them?

[kangmingtay]

Hey @sandbox-apps, yeah that's one of the main blockers we're facing currently - some of the auth providers implemented in the past did not keep track of the provider id. We're trying to come up with a solution to reduce any breaking changes. Any ideas will be greatly appreciated :)

[kangmingtay]

Hey @sandbox-apps, yeah that's one of the main blockers we're facing currently - some of the auth providers implemented in the past did not keep track of the provider id. We're trying to come up with a solution to reduce any breaking changes. Any ideas will be greatly appreciated :)

Resolved here. The idea is to check a new sign-in according to the following order:

[github-actions]

🎉 This PR is included in version 2.1.11 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[awalias]

just linking this here, I think it will be fixed by this change?

https://github.com/supabase/infrastructure/issues/1486

[kangmingtay]

just linking this here, I think it will be fixed by this change?

supabase/infrastructure#1486

@awalias i think this issue was already fixed here

[dshukertjr]

We ran into failing test on Gotrue-Dart with the latest Gotrue docker image where the user.AppMetaData["provider"] returned not string, but array of strings instead. I really like this update where you get a list of providers associated to a user, but this seems like a breaking change. Would this change go live on Supabase?

[kangmingtay]

Hey @dshukertjr, yes this will be a breaking change and we'll make sure to document it down. It's not going to go live on Supabase just yet as we're still testing it out in our staging environment but we're definitely looking to deploy it to prod sometime in October.

[dshukertjr]

Sounds good! Thanks @kangmingtay for for the explanation!

[bnjmnt4n]

Will an API be exposed to allow modification of the list of providers associated with a given account? Potentially, this could be useful to allow addition of multiple login options for an account, which have a different email address than the original user account.