auth icon indicating copy to clipboard operation
auth copied to clipboard

Expose provider name being used to log in

Open burggraf opened this issue 4 years ago • 1 comments

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.

burggraf avatar Jul 31 '21 18:07 burggraf

This is a great suggestion. It will likely be covered with the work we're doing with SAML where the provider used to log in as well as its properties (if any) are added to the access token so they can be used in RLS policies and other places.

hf avatar Sep 29 '22 13:09 hf