Invalid LinkedIn Profile URL Construction Using sub Claim

[indcoder]

In DirectOauthService.cs, the current code constructs LinkedIn profile URLs as:

https://www.linkedin.com/in/{linkedInId}

where {linkedInId} is taken from the sub claim in LinkedIn’s userinfo endpoint.

However, the sub claim is an opaque identifier (e.g., 782bbtaQ), not the vanity name that appears in public profile URLs. This results in invalid URLs such as:

https://www.linkedin.com/in/782bbtaQ

which do not resolve to user profiles.

Problem:

• LinkedIn’s userinfo endpoint does not provide the vanity name field needed to construct valid public profile URLs.
• Using the sub claim directly leads to broken links and incorrect assumptions about profile accessibility.
  Proposed Solutions:
• Remove profile URL construction if a vanity name cannot be obtained.
• Fetch additional user data from a separate LinkedIn API endpoint if vanity names are required.
• Use the sub claim only for internal identification, not for constructing public URLs.
  Acceptance Criteria:
• Code no longer generates invalid LinkedIn profile URLs.
• Either vanity names are fetched from the correct API endpoint, or profile URL construction is removed entirely.
• sub claim continues to be used safely for internal identification purposes.