Feature request

Is your feature request related to a problem? Please describe.

Right now, when getting a magic link or signup confirmation email, the link always sends the user to the site URL defined in the settings page. While this is great, I would like to be able to direct users to different parts of the app depending on where they are when login in/signing up.

Describe the solution you'd like

I can think of several ways of doing this.

• right now, I could add a redirect_to field in the auth.users table, set it when I trigger the magic link/signup email and read it on the other side to send the user to the right place. This means 2 db writes per login/signup (one before, one after to clear the field) and seems a bit heavy and brittle (what if there is an error just after the field is cleared? the link in the email will not work anymore)
• add an extra redirectTo parameter in the auth.signUp (or magic link) call, which would be passed on to the link in the email, and finally back to the page the user lands on (the site URL), so that the app can process this. so my siteURL could look like example.com/auth/postLogin?redirectTo=<theNextStep>

Describe alternatives you've considered

See above, I think the second option is much nicer and easier to manage (at least from my perspective 😉 )

Additional context

Add any other context or screenshots about the feature request here.

Feature request

Is your feature request related to a problem? Please describe.

At the moment an invite handled by sending an email. It would be nice to:

• return the invite link when the /invite route is called
• optionally choose to send emails (eg, send by default, parameter to not send)

Additional context

• Requested by monitoro
• supabase/supabase#715

Feature request

Is your feature request related to a problem? Please describe.

In app_metadata.provoder in the user object, currently we can only get what provider did the user signed up with and not all the provides that the user has connected.

Describe the solution you'd like

Instead of providing only the initial OAuth Provider, provide an array of all the providers user has used in the past.

{
  // ...
  "app_metadata": {
-   "provider": "github"
+   "providers": ["github", "gitlab"]
  },
  // ...
}

This could be a massive breaking change, so here's an alternative solution:

Provide the current OAuth Provider and Dev's can record it on the application side.

Describe alternatives you've considered

N/A

Additional context

This can be used to show which OAuth Provider the user has connected and if they want to disconnect a provider or connect more, similar to the following:

ref: GitLab profile settings

it should wrap the /token?grant_type=password functionality

this is just to provide a simplified endpoint to the user

We should add two endpoints accessible by the admin:

r.With(api.requireAdminCredentials).Post("/disable", api.DisableUser)
r.With(api.requireAdminCredentials).Post("/enable", api.EnableUser)

we would need an is_disabled column on the users table which is checked before a token is requested, and returns an error "this user has been disabled by the admin" if is true

Currently there is no Gotrue method for deleting users.

We do have a delete user on the dashboard, but Copple says it directly removes the user from auth.users. We should support this directly in Gotrue so that others can call this via supabase-js and better for our audit trails, etc.

User request

the password recovery flow logs the user in and redirects the user to <SITE_URL>#access_token..etc.

need to add a query param either inside gotrue server, to let the user's app know that it's a password recovery

magic link currently returns sign in responses when user doesn't exist (access_token, or confirmation_sent_at etc.)

and returns nothing when user exists and magic link is sent, recover endpoint returns and empty json body {} so should standardize

As suggested by Nicolo, we should standardize the error responses coming from GoTrue, postgres, and realtime (and any other/future APIs) so that it's better DX when writing a client,

We can make this change on the servers themselves, but since postgrest and gotrue are fully/partially external may be harder to change, it might be an option to transform the errors within the client libraries/supabase-js, could be messy?

Nicolo also dropped this as a reference: http://spec.openapis.org/oas/v3.0.3#openapi-specification

Chore

Describe the chore

In the latest release (https://github.com/supabase/gotrue/actions/runs/560510377) the docker image didn't deploy:

I tried re-running the GitHub action and it skipped the release.

I then tried on my local machine and I'm getting

storage/dial.go:71:36: not enough arguments in call to columns.ForStructWithAlias
	have (interface {}, string, string)
	want (interface {}, string, string, string)

https://github.com/netlify/gotrue/blob/f023c23d846c98fafc8e227608d6059fb02845df/storage/dial.go#L71

This is the same as what I saw on the logs for the GitHub action (before they were cleared)

Hi Team,
Is it possible for email confirmation, we can ask users to enter the verification code rather than clicking the link?

we can use the existing recovery flow as a base but something with better DX would be nice

Feature request

Is your feature request related to a problem? Please describe.

When I go to auth/settings I see External Oauth Providers for Google, Github, Gitlab, and Bitbucket. My understanding is that for an ios app, you must also provide Apple as an oauth provider. Is this something you intend to support in Supabase?

Describe the solution you'd like

I would like to have Apple supported as an external Oauth Provider

Describe alternatives you've considered

From what I understand, apple's store guidelines require that if you allow another oauth provider you must support apple oauth. If I am building an app powered by supabase I would like to offer google oauth, but I want to make sure this is supported.

Additional context

If you update the email adress with supabase.auth.update, it will not replace the old one but create a "new_email" element in your auth.user object.

Therefore, when you try to log in again with the new updated email, it will not work and you'll have to use the old one.

Feature request

Internationalization for Authentication Email Templates

The Authentication Email Templates should be made available for i18n internationalization so you can send an email in any language based on the current language or locale setting.

So instead of having one set of templates, you'd have one set for each language your application supports. I.e. "en", "es", "fr", "de".

To keep existing compatibility you could leave the existing templates alone as the "default templates" but override those with a language-specific version of a language or locale code is set.

Describe alternatives you've considered

The only alternative would be to write a completely separate system, using a third-party email system, to replicate the automated features for password reset, email confirmation, etc.

Additional context

While it's relatively easy to create an internationalized login screen with libraries such as Angular's @ngx-translate/core, it's pretty awkward for a Spanish speaking user to sign up on a Spanish page then get an English confirmation email.

Bug report

Describe the bug

When signing in, GoTrue can return different error messages:

• No user found with this email
• Invalid Password

This allows malicious actors to probe if an account with a specific email exists.
The same goes for the password recovery feature, where GoTrue can return User not found.

Expected behavior

When signing in, return a unified error message, e.g Invalid email or password.
When recovering a password, do not tell the user if the email is not associated with an account.

Feature request

Currently, if a recovery/magic link is expired, supabase will show a json error which is not a good user experience. Rather we should redirect back to the merchant site with an error_description URL param maybe?

Additional context

Add any other context or screenshots about the feature request here.

https://golang.org/src/net/http/cookie.go

https://medium.com/@nabil.servais/using-github-actions-to-test-your-go-code-on-arm64-ce581e646cb

https://medium.com/swlh/using-github-actions-to-build-arm-based-docker-images-413a8d498ee

https://github.community/t/does-github-actions-support-multiple-os-architectures/16526

We currently check the JWT for roles service_role and supabase_admin, we should instead read an env var with a list of roles to check and loop through all:

e.g.

ADMIN_ROLES=supabase_admin,service_role,my_special_role

this allows more flexible uses of gotrue outside of supabase

I'm submitting a ...

• feature request

Summary
MFA would be a very nice addition to the auth module.

Here are two standards that I think should be supported:

• HOTP and TOTP (e.g Google Authenticator, FreeOTP)
• FIDO U2F (e.g YubiKey, Google Titan Key)

we don't want to be too opinionated on the password requirements, but it may be useful to have a basic requirement of min 6 characters

this should only be enforced when the caller is trying to set a password (since oauth rows won't need an associated password)

see: supabase/ui#137

Chore

Describe the chore

The supabase.auth.logout() function takes consistently more than 2 seconds to resolve. Is there anything we can do to speed this up? It's a bit awkward for that much delay after hitting the signout button.

Additional context

Tested here: https://nextjs-subscription-payments-starter.vercel.app/

Feature request: Allow a user to log in with multiple providers

Requirement

A user should be able to log in with more than one provider. For example:

1. A user authenticates with Facebook and creates an account in my app.
2. The user decides to quit Facebook.
3. The user wants to log back into my app at a later time, but cannot. The user should be at minimum be able to "sign in with email" and enter their email address and a password, then verify their email, and get access to their user account.

Another example:

1. User creates an account in my app with Google.
2. User comes back a month later and can't remember which provider they used, so they try to log in with Facebook. They can't -- because they already have a Google-provider account.
3. The user should be able to authenticate with Facebook now as well, assuming they use the same email address with both providers.

Firebase handles this, albeit not very elegantly. This is an opportunity to make a much more flexible authentication system.

Describe alternatives you've considered

At this time, it appears that you'd need to create a separate user account, which would not give the user access to data they have previously created inside my app.

Additional thoughts

If a change to the core user object isn't possible here, how about a table of user aliases at least, where a user can log in using a provider (even if it's not their "first" or "main" provider) then once logged in the credentials are set to that of the main account. Not super clean, but might be quicker to implement.

https://medium.com/@pedram.esmaeeli/generate-swagger-specification-from-go-source-code-648615f7b9d9

Feature request

Is your feature request related to a problem? Please describe.

Our app would like to authenticate users via facebook and then pull a list of friends from that user.

Describe the solution you'd like

Ideally supabase can authenticate with facebook for us, and store an auth token in the database that we can use to pull data from facebook in a long running task somewhere on a daily interval.

Describe alternatives you've considered

The alternative is not really feasible using postgrest. There is a good amount of complicated client to server communication that I do not want to write in sql statements. That means the alternative we are using for now rolling our own rest server that talks to a postgres database

Additional context

facebook is an oauth provider https://en.wikipedia.org/wiki/List_of_OAuth_providers

reported by @thorwebdev

so that login() method on supabase-js doesn't have to make a double fetch on login to get the user

This may be possible already by setting up some endpoints on user app which forward to callback domains but need to test to verify but the main work would be adding the ability to set the env var GOTRUE_EXTERNAL_GOOGLE_REDIRECT_URI from the Supabase dashboard

Feature request

Is your feature request related to a problem? Please describe.

I want to use supabase auth both during development (http://localhost:3000) and production (https://myawesome.domain.com). But I can only set one 'site url' in the auth setting. I can't enable auth for both domains (dev and prod) at the same time.

Describe the solution you'd like

I want to be able to add two or more domains to 'site url', so that both the dev and prod domain can use supabase auth at the same time.

Describe alternatives you've considered

During development, I need to switch supabase auth 'site url' to my dev domain (http://localhost:3000), but this brings down my production website since people can't login anymore.

so that people can verify directly with gotrue from their confirmation email

can use the POST doc as a spec but note that it does not need to support password reset since this needs to first to the user app for the end-user to choose a new password, and also passwords should not be passed a query params

Question

Additional context

From supabase/supabase#143

Are the server responses format documented ? If they are I couldn't find them otherwise they should definitely be added to the doc at some point. It would make it easier to display accurate errors to the user (e.g. this mail address is already used, password too short, etc).

Edit: To be clear I did find some documentation here but I'm interested in the format of errors which are not in the readme.

we should try and change this to type=magiclink in this case

not easy without making schema changes to add magic_link_sent_at but maybe we need to add this

Feature request

For letting users anonymously enter into the application, and then if they want to continue, they can upgrade their account.

Describe the solution you'd like

Ability to sign in without any credentials.

currently referrers are restricted to the origin (SITE_URL)

but mobile requirements mean that we need to be able to whitelist multiple domains via the supabase dashboard

Hi !

Would it be possible to have add a webhook on the auth setting so that we could send the email ourselves with the link passed as a parameter ?

Currently auth are different from my other emails because they're cannot be sent to same way my other emails are. I'm sure that I'm not the only one in this situation. Also, they're more frequently sent to spam than my normal ones because of the link and the smtp connection.

current email change email is sent to user

• add template to supabase dashboard
• gotrue confirmation url should be a get request to users endpoint with the email_change_token as a query param, which is confirmed and returns a new valid login session (hence invalidating older refresh_tokens that may have been opened on the old email) this is current implemented here

we recently added the ability to request additional scopes and return the provider_token,

we need to figure out the best way to persist this token so it can be used again later, perhaps in the app or user_metadata is a good place

alternatively add it in the auth schema as a table or column on auth.users

the default is currently 15 mins, we should reduce the default and also make sure the error is returned to the user if it is tripped and a new token is not generated first (since it invalidates the previous token)

currently recovery emails contain a link like:

<user-app>/?recovery_token=XXXXXXXX

which can then be used to do a:

but we can skip this step by embedding the verify link directly into the email

this may require a change in gotrue to allow making a /verify over GET

Feature request

Is your feature request related to a problem? Please describe.

Our organization is standardized on the Azure stack and as such we are required to use Azure AD for auth.

Describe the solution you'd like

Ability to authenticate via Azure AD over OAuth.

Describe alternatives you've considered

An alternative is not really feasible using Supabase without some hackery. I suppose we could have some weird callback system through another auth system that works with Azure AD that then creates a user in Supabase but it's going to get messy quickly.

Additional context

Azure AD supports OAuth 2.0 - https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/auth-oauth2

Improve documentation

Describe the problem

When I update the email of a user account, I receive a "Confirm email address change" with a email_change_token.
What should I do with it? Which end point should use to validate the new e-mail?

Thank you

can follow existing code for google/github etc.

verify token endpoint currently returns User not found if the token has expired, should instead return token expired error

or if not going to be called via API, then can also redirect to something like <SITE_URL>#error_description=token_expired

last_sign_in exists in the auth schema (auth.users.last_sign_in) but is not set anywhere in gotrue

there is an opportunity to update this value each time an access_token is generated by gotrue

it will then be shown on the supabase dashboard since it's already hooked up to read this value from the DB

Requested by one user

Related to this discussion.

We're using Firebase at the moment to sign up new users with 'Sign in with Github' and read/write to their repos. This is possible because Firebase lets you add scopes to the OAuth request so the user can grant additional permissions.

It looks like the current GoTrue Github scopes are hard-coded to just be the user's email.

I've tried doing a second trip to get the additional permissions manually (like repository.surf's workaround), but I'm hitting a wall.

I imagine the functionality in supabase-js might look like

const { user, session, error } = await supabase.auth.signIn({
  provider: 'github',
  providerOptions: {
    scope: 'repo admin:org'
  }
})

We're eager to migrate over to Supabase (love it so far), so let me know if there's anything I can do to help with this.