LinkedIn OAuth "prompt=none": not enough scopes
Why a silent (prompt=none) LinkedIn OAuth request fails when the previously granted scopes don't cover what you're now requesting.
By André Lugprompt=none tells LinkedIn to skip all interactive UI and either succeed silently against an existing grant or fail immediately. When the request includes scopes the member has never consented to — which covers every first connection and every scope upgrade — there is no grant to reuse, so the request fails. Drop prompt=none (or use prompt=consent) whenever the request includes a new scope.
prompt=none is an OAuth 2.0 parameter that tells the authorization server to skip any interactive UI — no login screen, no consent screen — and either succeed silently against an existing grant or fail immediately. When a LinkedIn OAuth request built with prompt=none asks for scopes the member has not previously consented to, there is no existing grant to reuse, so LinkedIn has no way to expand the grant without showing the member a consent screen. The request fails, and depending on how your OAuth client surfaces it, that shows up as an unauthorized_scope_error, a generic error page instead of the consent dialog, or an application-level message like "not enough scopes."
PostGate handles OAuth, publishing and delivery evidence for every network through one API. Start free or read the docs.
Why does this happen specifically on scope expansion?
A silent (prompt=none) OAuth request only ever returns scopes the member already granted in a previous, interactive authorization. If your app requests w_member_social for the first time — or requests it again after previously connecting with a narrower scope set like just openid profile — there is nothing for LinkedIn to silently reuse. The member has never seen a consent screen offering that scope, so LinkedIn cannot grant it without asking them, and prompt=none explicitly forbids asking. First-time connections and any scope upgrade both hit this the same way.
Where does this typically get built by accident?
Silent re-authorization flows are a reasonable pattern for refreshing an identity token in the background without interrupting the user — but they are the wrong pattern for the very first consent, or for adding a scope the member has not seen before. Integrations that generate their authorization URL from one shared function often default that function to silent mode for performance reasons, then hit this failure the first time a new scope (like w_member_social for posting) gets added to an app that previously only requested identity scopes.
The fix: drop prompt=none for any new consent
Remove prompt=none (or set prompt=consent) whenever the request includes a scope the member has not previously granted — which, in practice, means every first connection and every scope upgrade. Reserve prompt=none only for a background refresh of a token whose exact scope set the member already consented to. If you cannot tell in advance whether the member has already granted the scopes you are about to request, default to an interactive request; a member who already granted everything just sees the consent screen render and confirm instantly, while a member who has not gets the screen they actually need.
GET https://www.linkedin.com/oauth/v2/authorization
?client_id=...
&redirect_uri=...
&response_type=code
&state=...
&scope=openid%20profile%20w_member_socialHow does PostGate handle LinkedIn scope requests?
PostGate requests openid profile w_member_social together on every LinkedIn connection through an interactive consent screen — there is no silent step in the flow a customer's member could get stuck on. See LinkedIn API permissions for what each of those scopes unlocks, and what the heavier Community Management API tier requires beyond them.
Frequently asked questions
When is it safe to use prompt=none with LinkedIn OAuth?
Only for a background refresh of a token whose exact scope set the member has already consented to in a previous, interactive authorization. A silent request only ever returns scopes the member already granted — it can never expand the grant, because expanding it requires a consent screen and prompt=none explicitly forbids showing one.
Why did adding w_member_social break my silent LinkedIn login flow?
Because the member has never seen a consent screen offering that scope. If your app previously connected with a narrower set like openid profile and then adds w_member_social for posting, there is nothing for LinkedIn to silently reuse. This often happens when one shared function generates authorization URLs and defaults to silent mode for performance — it works until the first new scope is added.
What error does LinkedIn return when prompt=none fails on new scopes?
It depends on how your OAuth client surfaces the failure: an unauthorized_scope_error, a generic error page shown instead of the consent dialog, or an application-level message like "not enough scopes." All of them trace back to the same cause — a silent request asking for scopes with no existing grant to reuse.
What if I cannot tell whether the member already granted the scopes?
Default to an interactive request. A member who already granted everything just sees the consent screen render and confirm instantly, while a member who has not gets the screen they actually need. Reserve prompt=none strictly for background refreshes where you know the exact scope set was already consented to.
