Sign In with LinkedIn granular OAuth scopes: legacy token access after refresh or re-authentication is undefined

Answer to the Core Questions

1. Refreshing a legacy‑scoped token: OAuth 2.0 dictates that a successful POST /oauth/v2/accessToken with a refresh_token returns a token that carries the same scope value that was originally granted. In practice, LinkedIn’s current implementation keeps the legacy scope set (e.g., r_basicprofile r_emailaddress) intact when you refresh an access token, so you continue to receive the same profile fields you had before the token expired.

2. Re‑authenticating (user logs in again): The grant you receive depends on the scope you request in the new authorization URL. If you request granular scopes (e.g., openid profile email), the new access token will contain only those scopes. If you still request legacy scopes, LinkedIn may accept the request and issue a legacy token, but this is not guaranteed; enforcement can vary by app tier, verification status, and region. The token’s scope claim is the reliable indicator of the granted permissions.

Confirmed Facts (from LinkedIn documentation & protocol spec)

• Token refresh preserves the original scope value unless the authorization server explicitly revokes or narrows it.
• LinkedIn’s migration to OpenID Connect scopes is documented, but no public sunset date for legacy scopes has been announced.
• The access token payload contains a scope claim that lists all permissions the token can use.
• App tier, verification status, and geographic region can influence whether legacy scopes are honored during refresh or re‑auth.

Likely Behavior (subject to the above caveats)

1. After a refresh, the legacy token will still expose the profile fields you originally consented to.
2. During a new sign‑in, the token will reflect the scopes you explicitly request; if you ask for granular scopes only, you’ll lose any legacy‑only fields.
3. Your application can detect a narrowed grant by inspecting the scope claim in the access token before making profile‑dependent API calls.

Practical Steps to Verify for Your App

1. Create a sandbox LinkedIn app and configure it with legacy scopes (e.g., r_basicprofile r_emailaddress).
2. Obtain an access token via the standard OAuth flow and note the scope value returned in the token response.
3. Refresh the token:

   curl -X POST https://www.linkedin.com/oauth/v2/accessToken \
     -d grant_type=refresh_token \
     -d refresh_token=<YOUR_REFRESH_TOKEN> \
     -d client_id=<YOUR_CLIENT_ID> \
     -d client_secret=<YOUR_CLIENT_SECRET>

   Inspect the scope field in the refreshed response; it should match the original legacy scopes.
4. Re‑authenticate with granular scopes only (e.g., openid profile email) and compare the new token’s scope claim. If it contains only the granular scopes, you’ve lost legacy fields.
5. Detect narrowed scopes at runtime by parsing the scope claim before making API calls that rely on legacy fields. If a required field is missing, prompt the user to re‑authorize with the necessary granular scope.

What to Ask Next (if the recommendation changes)

To fine‑tune the guidance for your specific environment, please provide:

• Your app’s verification status (verified vs. unverified).
• The LinkedIn app tier you’re on (free, paid, or partner).
• The geographic region of your target user base.

These details can influence whether legacy scopes are honored during refresh or re‑auth and whether LinkedIn has already enforced the granular‑scope migration for your app.