Expose provider name being used to log in

Start by tracing the signIn entry point through authentication and access-token issuance, focusing on how app_metadata.provider is currently populated. Determine where the provider used for the current login can be exposed, then verify that the access token reports it consistently for email, magic link, phone, and third-party OAuth logins.

Feature request

Expose the name of the provider that's being used to authenticate a given user.

• A project can have 12 different ways to log in (email, magic link, phone, plus 9 third-party OAuth providers.)
• A user may sign up using one provider, say google, which results in the provider being set to google in the app_metatdata like this:

app_metadata: {
  provider: "google"
 }

• Then the user may later log in using the Facebook provider, but there's no easy way for the developer to know that the login came from Facebook, because the app_metadata will still always say 'google' as the provider.

Describe the solution you'd like

Adding the currently used provider name to the access token would be fine. Basically anywhere you can expose the name of the provider that was just used to authenticate the user would be fine. The use case here is to log each different provider a user has used to log in, to help troubleshoot authentication issues for a user.

"I tried to log in but it didn't work!" <-- would be much easier to troubleshoot if we could see they registered using email then logged in using twitter, then google, then github.

Describe alternatives you've considered

• We could log the attempt to log in from the client, since the client sets the provider name when calling supabase.auth.signIn(), but that's not a real login, that's just an attempt that might not be completed successfully.
• We could add the provider to the redirectTo parameter of the signIn() call:

redirectTo: `${window.location.origin}?provider=${provider}`

• This would require the developer to parse this information from the search part of the app's querystring, then make a second call back to the database to log this info
• This would also require that every possible provider is added to the Additional Redirect URLs, which in an app with every possible auth provider, would make it a significant list. If you wanted to have redirect URLs for localhost (dev) and production, you might need 2 dozen or more redirect urls: http://localhost:8100?provider=facebook,http://localhost:8100?provider=google etc.