auth
auth copied to clipboard
supabase
Return oauth_secret_token for OAuth1.0 providers
Feature request
Currently, only the provider_token (oauth_token) is being returned for OAuth1.0 providers. In the future, we would either want to return the oauth_secret_token as well or not at all.
Is your feature request related to a problem? Please describe.
Returning both the provider_token and oauth_secret_token will allow the service to retrieve a user's credentials in the future without having to ask the user for permission again. In the case of Twitter, the service can retrieve a user's tweets / retweet count / etc...
Describe the solution you'd like
OAuth1.0 tokens generally have a longer lasting lifetime compared to OAuth2.0 (Twitter's tokens do not expire but can be revoked by the user whenever). We can send the oauth_secret_token as part of the query parameters returned together with the provider_token.
Additional context
- Is it secure / a good practice to send the
oauth_secret_tokenas a query parameter?
+1 for this one! If it works out it would be helpful for me! I have a twitter app that makes use of secret on user's behalf!
If it's not a priority right then please let me know, thanks!
@kangmingtay Hi Kang, any ETA/plans for this one? I've been facing auth issues in my existing setup and would really want to use Supabase before I get too many users in the app(it's already on production 😅)
@kangmingtay @kiwicopple Can we get an update on this one? The provider_token on it's own is not too helpful for Twitter.
Hey @rishimohan, @mike-wax, we're currently in the midst of refactoring gotrue so that we can securely return the provider_token & provider_secret token (for twitter's case). We didn't support it initially because the supabase-js client library stores tokens in local storage. This is a security concern for twitter as twitter uses oauth1.0 - which returns tokens that are long-lived. If an attacker manages to get the tokens from local storage, the tokens do not expire and only the user can revoke them.
@kangmingtay thanks! Are you planning to store the secrets in supabase encrypted?
@kangmingtay thanks! Are you planning to store the secrets in supabase encrypted?
Nope, for oauth1.0 (twitter), we don't intend to store it on the browser at all. We'll be returning the provider_token & provider_secret_token in the api response. For oauth2.0, the provider_token will be returned the same way as mentioned above and the provider_refresh_token will be stored as a http-only cookie. We'll be providing an endpoint to refresh your provider_token as well.
Given that this was implemented in #490, I'm closing the issue. Feel free to re-open it.
@rishimohan I'll reopen the issue as this was only added to OAuth2.0 providers, while Twitter uses OAuth1.0.
Return oauth_secret_token for OAuth1.0 providers
Will this be implemented?
Otherwise will look at different solutions.
Thank you.
