Persist additional scopes provider_token about auth HOT 9 CLOSED

Having looked at #127 that PR and update (and trying out a new fresh GitHub signin) now that there is a user_name in the raw_user_meta_data, I should be able to join in data that extracts user_name form the raw_user_meta_data json with other data that contains the GitHub username.

Perhaps I'll create a function in auth to extract user_name or other helpers.

Thanks @dsumer for this!

from auth.

Given that refreshSession()refreshes the access_token but removesprovider_token from the session w/out a way to refetch it without the user authenticating, persisting the provider_token takes on more importance if one builds an app that relies on the token to be there when interacting with that third party.

In my case integrating with GitHub I know that I want:

• the user's GitHub username upon authenticating right away on user_meta_data (in addition to the current full_name and avatar_url
• The provider_token (and maybe provider_refresh_token available

Given that refreshSession removes it from the access_token/JWT, these provider_tokens could be stored on the JWT in app_metadata or the user table -- or preferably both.

One question I had about storing the provider_token on the JWT is:

If the provider token is on the JWT in app or user metadata anyone can decode the JWT but just not verify it -- might that let the token out in the wild? And then anyone with that provider token can act as the user?

This is similar to the reason Auth0 doesn't set email values in the user data on the JWT unless you use a rule or hook to explicitly set it. That's more personal info that it doesn't want to set on the JWT for just anyone to see by decoding it.

Therefore, perhaps persisting the provider_token on the auth schema user would be a better option?

from auth.

I have been struggling so much with this provider token. Quite easily I managed to use Azure accounts to log in, but from there I'm stuck with actually getting/using an access token to access the Azure API. Since a recent update I do get a provider_token back, but the value of it doesn't seem to be an access token (while it does for for instance Github). Right now the easiest approach is completely ignoring supabase's auth and doing the token management yourself, which unfortunately defeats the purpose of using supabase.

from auth.

Has there been any decision made how best to support the use case of:

retrieving the user's GitHub username upon authenticating right away on user_meta_data (in addition to the current full_name and avatar_url)

The scenario I have is that I would like to link a set of GitHub profile info that I have (includes their GitHib username) to their Supabase user account. If on auth, I could fetch that username, I could easily link.

Thanks!

from auth.

Therefore, perhaps persisting the provider_token on the auth schema user would be a better option?

agreed, and we should also persist the provider_refresh_token in the auth schema

The scenario I have is that I would like to link a set of GitHub profile info that I have (includes their GitHib username) to their Supabase user account.

we are actually about to start migrating the supabase dashboard from auth0 to gotrue, so we will also require this functionality. We'll let you know what we decide on whether to grab it as part of the initial fetch vs make a follow up request, one thought is that the JWT itself might get quite large if we fetch all available data but perhaps we could just include username for now as per your request @dthyresson and put it in app_metadata?

@gl3nn I haven't tested this with Azure, what format does the azure provider_token take? Whatever it is, it is presumably used here to grab the initial user data: https://github.com/supabase/gotrue/blob/45d0e8a660f0b8c8036000cfe4a61a5d6b1562be/api/provider/azure.go#L65

from auth.

we could just include username for now as per your request @dthyresson and put it in app_metadata?

The username is all I need to link the identities, so if that is possible then perfect!

I'll look more into how Auth0 did multiple identity and account linking (https://auth0.com/docs/users/user-account-linking) but not sure if this info was on the JWT:

  "identities": [
    {
      "provider": "google-oauth2",
      "user_id": "115015401343387192604",
      "connection": "google-oauth2",
      "isSocial": true
    }
  ],
  "user_metadata": {
    "color": "red"
  },
  "app_metadata": {
    "roles": [
      "Admin"
    ]
  },

but an identities collection with the provider, uid, username ... might be an option.

Actually, I'm not sure I actually need it on the JWT, just in the auth.users record so I can join on my existing "identities" that has the GH username and the auth.users info.

from auth.

@awalias Another RedwoodJS user today asked me about retrieving the GitHub username.

They had to do something like:

 const session = supabase.auth.session()

      const octokit = new Octokit({
        auth: session.provider_token,
      })
      const { data } = await octokit.request('GET /user')

      const username = data.login

on the web client side to get that info -- which isn't ideal.

It'd be great to have that info on the auth.users and either query it or we can use the Supabase client with the JWT for the user to get their identity and profile info.

from auth.

Hey everyone, we have merged in this PR (#641) to support returning the provider_refresh_token in the query fragment. That way, you will be able to refresh your provider_token if it expires. However, we have decided that at this point, we will not be persisting the provider_token and provider_refresh_token in gotrue.

Will be closing this issue for now, but feel free to reopen it if you have any questions or feedback! Thank you!

from auth.

Hey everyone, we have merged in this PR (#641) to support returning the provider_refresh_token in the query fragment. That way, you will be able to refresh your provider_token if it expires. However, we have decided that at this point, we will not be persisting the provider_token and provider_refresh_token in gotrue.

Will be closing this issue for now, but feel free to reopen it if you have any questions or feedback! Thank you!

@kangmingtay When this decision was made, was refreshing the provider_token from application client code using the provider_refresh_token tested to ensure there is a reasonable way to do that?

If so, what is the correct method for completing such requests?

I've been trying everything I can think of to get Microsoft/Azure to accept the token refresh and it seems this is simply not allowed because the origin of the token refresh request does not match the origin the token was issued to.

In particular, Microsoft returns this error

AADSTS9002326: Cross-origin token redemption is permitted only for the 'Single-Page Application' client-type. Request origin: 'http://localhost:8080'

This is due to the Supabase callback url https://<project_id>.supabase.co/auth/v1/callback being registered in AzureAD as a "Web" type, which is how it is supposed to be according to the documentation here https://supabase.com/docs/guides/auth/social-login/auth-azure.

Trying to switch that to "SPA" type, results in a failure to authenticate since Supabase is running the PKCE from a trusted server using the ClientId and ClientSecret.

So far the only way I can find to use both Supabase auth and the provider's own API is to make the user sign-in twice, which is terrible from a UX standpoint.

from auth.