Hey, I’m new to Auth0, I have been able to add the required scopes to the access token from LinkedIn, but when I try and use the token (which I got from the management api) I get a 403 forbidden error, I checked the token using LinkedIn’s API to check the token endpoint, and I can see that it has the required scopes. Any ideas what i’m doing wrong.
export default handleAuth({
login: handleLogin({
authorizationParams: {
connection_scope: 'w_member_social',
}
})
});
This adds the correct scope. As you can see in the screenshot the access token has the scope
The URL I am trying to call to is https://api.linkedin.com/rest/posts
Request Body
{
"author":"urn:li:person:ID",
"commentary": "Hello",
"visibility": "PUBLIC",
"distribution": {
"feedDistribution": "MAIN_FEED",
"targetEntities": [],
"thirdPartyDistributionChannels": []
},
"lifecycleState": "PUBLISHED",
"isReshareDisabledByAuthor": false
}
Response
{
"status": 403
}
Hi Gurpreet 
This adds the correct scope. As you can see in the screenshot the access token has the scope
How are you determining that the correct scope(s) have been added to the LinkedIn Access Token? Are you decoding it somehow? I was under the impression that LinkedIn Access Tokens are not in JWT format It would be good if you could share a decode of the token; it could be that the LinkedIn Access Token you’re acquiring via the Auth0 Management API does not have the scopes you desire or has already expired? Please do not share any decoded token in a public forum unless it has been security sanitised first.
If your application is looking for a LinkedIn specific Access Token in order to call LinkedIn specific APIs - either directly, or via an SDK - then you will typically need to redirect to the LinkedIn Authorization server directly in order to obtain said token. You can do this once authentication via Auth0 has completed, and it should be a seamless operation - i.e. the user should not be asked to interactively login - as the (LinkedIn) SSO session already established by authenticating via Auth0 will be used.
For convenience, Auth0 typically stores the Access Token that might returned by an upstream IdP as part of first-factor authentication. And Auth0 typically stores such a token as part of the user’s profile record in the corresponding entry in the identities array, and accessible via a call to the Auth0 Management API. However, such tokens are typically short-lived, and typically are provided so that Auth0 Extensibility - such as an Action, Rule or Hook - can call upstream IdP services to obtain additional information about a user as part of the login process. Auth0 does not typically store any Refresh Token delivered by an upstream IdP.