Client‑credentials grant yields 401 on user‑scope endpoints

Question

The goal is to clarify whether a token obtained via LinkedIn’s client‑credentials grant can be used to call user‑level endpoints such as /me when the request includes a user‑specific scope like r_liteprofile.

The current documentation states that the client‑credentials grant is limited to application‑level scopes, but it does not explicitly say whether requesting a user‑scope results in an immediate token rejection or a token that later fails with a generic 401 error. This ambiguity leaves integrators uncertain about the exact cause of the failure and whether the grant type itself is incompatible with any user‑scope.

Does LinkedIn reject the token request outright when a user‑scope is included in a client‑credentials grant, or does it issue a token that subsequently fails on user‑scope calls? If a token is issued, what error information (if any) is returned to distinguish a scope mismatch from a grant‑type limitation? Which grant type should be used for server‑to‑server integrations that require access to user profile data while still adhering to LinkedIn’s policy?

Tasadduq Burney · Answer

Direct AnswerLinkedIn's token endpoint rejects the request outright with HTTP 400 when you include a user-level scope (e.g., r_liteprofile, r_emailaddress) in a client-credentials grant. It returns {"error":"invalid_scope","error_description":"Invalid scope requested"}. You do not receive a token that later fails with 401.Confirmed BehaviorToken endpoint (client_credentials + user scope): HTTP 400, invalid_scope error. The grant type only accepts application-level scopes such as r_organization_social and rw_organization_admin.Resource endpoint (if a token somehow lacked the required scope): HTTP 401 with WWW-Authenticate: Bearer error="insufficient_scope". This path is not the documented flow; the token request fails first.Correct Grant for Server-to-Server User Profile AccessUse the Authorization Code grant with offline_access (refresh tokens). The flow:Direct the user once through LinkedIn's consent screen requesting r_liteprofile (and offline_access).Exchange the authorization code for an access token + refresh token.Store the refresh token securely (rotate before 365-day inactivity expiry).Use the refresh token to obtain short-lived access tokens for subsequent /me calls without further user interaction.LinkedIn does not support the JWT Bearer grant (RFC 7523) or any other non-interactive grant for user-scoped data.One Diagnostic CheckIf you are seeing a 401 on /me without a prior 400 at the token endpoint, confirm the exact scope parameter sent in the token request. A mismatch between the scope requested and the scope granted (e.g., requesting r_liteprofile but receiving only app scopes) would indicate the token request was malformed or the app configuration restricts available scopes.

Client‑credentials grant yields 401 on user‑scope endpoints

1 answer

Direct Answer

Confirmed Behavior

Correct Grant for Server-to-Server User Profile Access

One Diagnostic Check

Your perspective belongs here.

1 question comment