feat: Update to Slack OAuth V2

[zhawtof]

What kind of change does this PR introduce?

• Updates the Slack OAuth provider with the new Sign In With Slack V2.
• Creates a test for Slack, improving test coverage
• Moves the old Slack provider to slack_legacy. Some users might still rely on this provider after the creation of legacy apps is disallowed on June 4th.

What is the current behavior?

Fixes #1294

Current behavior uses the original Slack OAuth V1 which is sunsetting June 4th according to the changelog

What is the new behavior?

New behavior now leverages the new Sign In With Slack (SIWS) on OAuth V2 for Slack authentication.

Additional context

A ticket should be created for ending support on slack_legacy.

[zhawtof]

Hi @kangmingtay and @hf! There is an end-of-life for creating Legacy Slack Apps on June 4th.

I'm hoping we can check in by then so that Supabase will still support Slack OAuth.

Please let me know if there are any additional updates you would like to see.

[zhawtof]

As requested @kangmingtay I undid the changes to slack (from slack_legacy) and included a net new slack_oidc provider.

[kangmingtay]

thanks for the quick turnaround @zhawtof! i'll test this out later this week and if it's all good, we can merge it in

it would be nice if you can make a PR to update the slack oauth docs too - you can take a look at what we did for the linkedin oauth docs when we had to update the provider to support the new API

[zhawtof]

thanks for the quick turnaround @zhawtof! i'll test this out later this week and if it's all good, we can merge it in

it would be nice if you can make a PR to update the slack oauth docs too - you can take a look at what we did for the linkedin oauth docs when we had to update the provider to support the new API

Updated the docs @kangmingtay. Hopefully, the PR is now good to go.

After this change, I want to reference a new issue missing in Supabase Auth around Slack.

The legacy system allowed users to add additional scopes but with Sign In With Slack, that capability is no longer allowed. Details are here.

It's generally recommended that those scopes be added in subsequent requests. Because Supabase supports users with multiple login providers merging into one common user, an additional provider should be created for OAuth 2.0 that does not follow the OIDC protocol.

This would allow developers to have SIWS, where a user can log in with a single-click experience, and OAuth 2.0 (w/out OIDC), where a user has a 2-step process for approving the additional scopes. That way, all relevant scopes can be configured for the same user in Supabase.

This should be created in a separate ticket if we agree.

[kangmingtay]

@zhawtof

The legacy system allowed users to add additional scopes but with Sign In With Slack, that capability is no longer allowed.

I'm not too sure i understand this fully - are you referring to this note by slack:

A scope conflict occurs when attempting to combine Sign in with Slack (SIWS) user scopes with non-Sign in with Slack scopes in the same OAuth flow. Each set of scopes must be requested in a separate OAuth flow.

so it seems to me that if you need to request for a token with user scopes and granular bot scopes, you need to make 2 separate oauth requests with each set of scopes?

an additional provider should be created for OAuth 2.0 that does not follow the OIDC protocol. This would allow developers to have SIWS, where a user can log in with a single-click experience, and OAuth 2.0 (w/out OIDC), where a user has a 2-step process for approving the additional scopes. That way, all relevant scopes can be configured for the same user in Supabase.

Would be keen to hear how you plan to achieve this.

[coveralls]

Pull Request Test Coverage Report for Build 9452537318

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 30 of 68 (44.12%) changed or added relevant lines in 4 files are covered.
• 92 unchanged lines in 7 files lost coverage.
• Overall coverage decreased (-0.05%) to 57.544%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
internal/api/provider/slack.go	0	1	0.0%
internal/api/provider/slack_oidc.go	27	64	42.19%

Files with Coverage Reduction	New Missed Lines	%
internal/api/mail.go	7	60.65%
internal/models/cleanup.go	8	88.37%
internal/observability/request-tracing.go	9	81.98%
internal/api/provider/spotify.go	10	0.0%
internal/crypto/password.go	14	78.29%
internal/api/middleware.go	16	80.81%
internal/observability/metrics.go	28	4.96%

Totals
Change from base Build 9369008036:	-0.05%
Covered Lines:	8539
Relevant Lines:	14839

---

💛 - Coveralls

[zhawtof]

Thanks for cleaning up my tests @kangmingtay.

I'll also have to look at the OAuth2 flow without OIDC in a few weeks. We'll likely be a first consumer after I get SIWS working in my own Supabase app.

On that note, I am wondering what the expected timeline for merging and releasing this in an upcoming Supabase might be. I appreciate the support, and hopefully, this helps some Slack devs out there.

[kangmingtay]

@zhawtof it will probably be some time next week or after - merging the PR doesn't reflect that the version will be deployed on the platform immediately

for this PR specifically, we also need some time to make changes on the UI + backend to support the new configs added, as well as roll out any comms necessary to let folks know that we've added a new slack provider and plan to deprecate the old one.