Add support of the new LinkedIn API version format about aspnet.security.oauth.providers HOT 8 OPEN

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

from aspnet.security.oauth.providers.

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!

from aspnet.security.oauth.providers.

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?

from aspnet.security.oauth.providers.

Thanks for raising this issue.

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

from aspnet.security.oauth.providers.

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

from aspnet.security.oauth.providers.

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/).

from aspnet.security.oauth.providers.

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.

from aspnet.security.oauth.providers.

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 😃

from aspnet.security.oauth.providers.