feat: add new Linkedin OIDC due to deprecated scopes for new linkedin applications

[josmo]

What kind of change does this PR introduce?

This PR introduces a new linkedin provider to address issues related to the current LinkedIn provider no longer being available for new applications.

What is the current behavior?

LinkedIn applications created after 1st of August experience difficulties while attempting to log in with GoTrue due to incorrect scope requests.

Relevant issue: #1216 (comment)
Relevant initial fix however would lead to breaking existing apps - #1232

What is the new behavior?

This PR aims to rectify the issue by adding a new provider with the updated OAuth scopes. Specifically, the scopes openid, email, and profile will be utilized. Additionally, the method of collecting profile information is updated, employing the /v2/userinfo API endpoint.

Visual changes: No visual changes.

Additional context

I've taken the initial updates from PR #1232 into the new providers while also adding the relevant settings and provider implementations. I don't know much in terms of this library so would love to get additional feedback.

I validated that the - http://localhost:9999/authorize?provider=linkedin-oidc workflow worked locally and had the relevant information in the Claim

[josmo]

I could also see updating the existing Linkedin provider to default with the original r_emailaddress and r_lightprofile scopes, while having the option to use new scopes.

[alexcraig043]

Thanks for being the one to tackle this finally! I think this is the PR from the original LinkedIn integration if it helps at all / if you want to add tests.

#238

[kangmingtay]

Hey @josmo, thanks for your contribution - just wanted to let you know that this is on the auth team's radar but we're currently quite tight on bandwidth so it might take a week for this to be reviewed. I've tested the happy path locally and it seems to work but right now, i'm looking at how we can support both the old and new implementation in a way that's not confusing for our users on the hosted platform. It would really help if you know about the following:

1. Can existing linkedin oauth apps that were created before this change work with the new API if they pass it the r_liteprofile and r_emailaddress scopes instead of openid, email, profile?
2. Is there a way to detect if the oauth app created is using the deprecated scopes or the new ones?

[josmo]

@alexcraig043 I'll take a look and see if I get some time to add tests :)

Hey @josmo, thanks for your contribution - just wanted to let you know that this is on the auth team's radar but we're currently quite tight on bandwidth so it might take a week for this to be reviewed. I've tested the happy path locally and it seems to work but right now, i'm looking at how we can support both the old and new implementation in a way that's not confusing for our users on the hosted platform. It would really help if you know about the following:

1. Can existing linkedin oauth apps that were created before this change work with the new API if they pass it the r_liteprofile and r_emailaddress scopes instead of openid, email, profile?
2. Is there a way to detect if the oauth app created is using the deprecated scopes or the new ones?

@kangmingtay No worries on timing and totally get wanting something that's not confusing - in terms of questions

1. I don't have access to an old legacy app, so sadly my ability to test the various options is limited - The route to test, would be if the new scopes can be passed to the old apps and have it still work. Then we don't need two and just the new one, but we need someone with an old app to verify. The old scopes don't work with new apps.
2. I don't know of a way to check - There "might" be a way to try the old/new flow and then based on the error try the other flow, however that seems a bit janky to me.

[kangmingtay]

hey @josmo, thanks for helping to add the new linkedin provider, we'll need some time to roll this out to the platform so that existing apps can continue to work with the old linkedin API

[github-actions]

🎉 This PR is included in version 2.97.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[alexcraig043]

Thanks for committing this change!

I'm currently getting

{"code":400,"msg":"Unsupported provider: Provider linkedin_oidc could not be found"}

when I try to call

  ({ data, error } = await supabase.auth.signInWithOAuth({
        provider: "linkedin_oidc",
      }));

Is "linkedin_oidc" the correct provider to use? I updated my supabase-js package, but is there anything else I have to update?

[kangmingtay]

@alexcraig043 we haven't deployed this to the hosted platform yet but we're planning to do so in the next week. There are bunch of backward compatibility checks to make sure that we don't break existing users using the old linkedin API. If you need this urgently, please reach out via https://supabase.com/dashboard/support/new.