Add support of the new LinkedIn API version format

[arlek777]

Provider name

AspNet.Security.OAuth.LinkedIn

Expected behavior

The LinkedIn provider is updated to support LinkedIn's new API version format that is introduced in June 2022. The old version (which is used now by the provider) will be shut down on 30 June 2023. Here is an official page: https://learn.microsoft.com/en-us/linkedin/marketing/versioning?trk=eml-mktg-cust-202305-global-api-migrations-june&src=e-drip&mcid=7057115242148806657&view=li-lms-2023-04

Actual behavior

The LinkedIn provided uses the old API version (or I haven't found a new one in the repository).

Additional information

Accordingly to the documentation, it shouldn't take more than 15 minutes. I can also update it manually in my project by overriding Defatuls but it would be great to have a working NuGet package after 30 June 2023.

[martincostello]

Thanks for raising this issue.

As you have a working integration, would you be willing to submit a PR to do the necessary changes?

[arlek777]

Hello, ok, sure, I will submit a new PR.

[solrevdev]

Hi all,

FYI, I submitted a ticket to Linked In about this because while I was able to move some of my /v2/me requests over to /rest/me some others like /emailAddress did not have a new /rest version.

The response stated that the new API version format for now is only relevant for LinkedIn Marketing Solutions(LMS) API calls not OAuth logins etc.

I double checked with them as the email I got did seem to suggest my app would need changing but they were clear that my app which uses AspNet.Security.OAuth.LinkedIn would not need to change and that we can continue with the /v2 calls.

I've pasted the relevant bits from my ticket with them below.

Hope this helps.

Hello John,

Thanks for writing in to check on this!

At present, versioned APIs are only available with LinkedIn Marketing Solutions(LMS). Other programs still work on v2.

I can see your app uses Sign in with Linkedin, which has /me and /emailAddress. Please continue using /v2 calls. Similarly, all Oauth calls are still on v2.

No action needed from you end at the moment. When other programs including Sign In is moved to versioning we will sure notify via our Newsletters.

More details in here - https://learn.microsoft.com/en-us/linkedin/marketing/versioning?view=li-lms-unversioned#what-about-other-linkedin-apis-outside-of-marketing

Then when questioned about why I got the email:

Hello John,

Im actually checking with the team about the validation done before triggering this email notifications.

From what I see it looks like its been sent out to all who have atleast one program provisioned to their app.

Rest assured, /emailAddress not yet moved to version i.e we don't have /rest endpoint for it. /me we do because its come to many programs.

One more way to verify if the endpoint is moved to /rest or not is by checking the document. If you see Sign in With LinkedIn you notice there is no version documents where are the Marketing solution API does. SS below for your reference

Hope this helps! Have a good day!

[solrevdev]

UPDATE

I was just going to add the Sign in with LinkedIn product that the AspNet.Security.OAuth.LinkedIn library handles nicely to a new app that I am building

However, I could not find it as it seems that this has now been deprecated https://learn.microsoft.com/en-us/linkedin/consumer/integrations/self-serve/sign-in-with-linkedin

We now have to "Sign In with LinkedIn using OpenID Connect" https://learn.microsoft.com/en-us/linkedin/consumer/integrations/self-serve/sign-in-with-linkedin-v2

Does this mean we need to migrate and upgrade existing apps?

And does the AspNet.Security.OAuth.LinkedIn library handle this new OpenID Connect way of signing in with Linked In already?

Has anyone been through this new process yet that could give me some pointers or have any information that could help?

@martincostello and @arlek777 is this something either of you have seen yet?

I'll carry on doing some digging but wanted to mention it here. Maybe I should have opened a new issue?

[martincostello]

Sorry, no, this isn't something I've been looking into.

[kevinchalet]

And does the AspNet.Security.OAuth.LinkedIn library handle this new OpenID Connect way of signing in with Linked In already?

No, it doesn't: the authorization and token endpoints used by the Sign In with LinkedIn using OpenID Connect API (formerly known as Sign In with LinkedIn V2) are the same, but the userinfo endpoint has changed (it is now OIDC-compliant, which means it now returns standard claims and you're no longer required to send a fields parameter).

We'll of course accept a PR that updates the provider to support the V2 API 😃

Alternatively, the OpenIddict client has a built-in LinkedIn integration that uses the V2/OIDC service (more info here, if you're not familiar with OpenIddict and its web providers: https://kevinchalet.com/2022/12/16/getting-started-with-the-openiddict-web-providers/).

[solrevdev]

And does the AspNet.Security.OAuth.LinkedIn library handle this new OpenID Connect way of signing in with Linked In already?

No, it doesn't: the authorization and token endpoints used by the Sign In with LinkedIn using OpenID Connect API (formerly known as Sign In with LinkedIn V2) are the same, but the userinfo endpoint has changed (it is now OIDC-compliant, which means it now returns standard claims and you're no longer required to send a fields parameter).

We'll of course accept a PR that updates the provider to support the V2 API 😃

Alternatively, the OpenIddict client has a built-in LinkedIn integration that uses the V2/OIDC service (more info here, if you're not familiar with OpenIddict and its web providers: https://kevinchalet.com/2022/12/16/getting-started-with-the-openiddict-web-providers/).

Thanks @kevinchalet I'm really not familiar with OpenIddict at all, I would much prefer to carry on using this, so let me have a stab at adding a PR to support this.

Any preferred way of me handling V1 (which still seems to work) and V2/OpenID Connect as in any prior art where this has been done before in the code.

I'll give it a go anyway.

Oh and for what it's worth I've replied to my original ticket about the endpoints that I made a while ago mentioning this to see what LinkedIn have to say/offer.

[kevinchalet]

Any preferred way of me handling V1 (which still seems to work) and V2/OpenID Connect as in any prior art where this has been done before in the code.

I'll give it a go anyway.

To simplify things, we'll probably want to just use the V2 service, even if it's technically breaking (you need to enable the V2 service via the LinkedIn portal and the claims are not the same). I don't think it's worth trying to support both versions 😃