LinkedIn connect fails with "Not enough scopes" — OAuth flow uses prompt=none, so newly-added member/org scopes are never granted

[dnlsemf]

📜 Description

Connecting LinkedIn (both personal and Company Page) fails with:

"Could not add provider. Not enough scopes, when choosing a provider, please add all the scopes."

The LinkedIn app is fully and correctly configured (verified company app, all required scopes present, both redirect URIs registered, Advertising API approved). The OAuth callback returns a valid code (no error param), but Postiz still rejects the connection for insufficient scopes.

Root cause appears to be that the LinkedIn authorize URL generated by Postiz contains prompt=none. This performs silent authorization and only returns scopes the user has previously consented to. On a first-time connection — or after new scopes are added to the app — there is no prior consent, so LinkedIn returns a token missing the member/org scopes, and Postiz throws "Not enough scopes". There is no way to force an interactive consent screen from the UI.

👟 Reproduction steps

1. Configure a LinkedIn app with all scopes: openid, profile, w_member_social, r_basicprofile, rw_organization_admin, w_organization_social, r_organization_social (Advertising API approved so org scopes are grantable).
2. Set LINKEDIN_CLIENT_ID / LINKEDIN_CLIENT_SECRET in the Postiz env and restart.
3. Register both redirect URIs in the LinkedIn app: https:///integrations/social/linkedin and https:///integrations/social/linkedin-page
4. In Postiz: Add Channel → LinkedIn (or LinkedIn Page).
5. Complete the LinkedIn login. The callback URL returns a valid ?code=... (no error).
6. Postiz fails with "Could not add provider. Not enough scopes…"

👍 Expected behavior

Postiz should trigger an interactive LinkedIn consent screen (i.e. NOT prompt=none) when connecting a channel, so the user can grant all requested member/organization scopes. The connection should then succeed and the token should carry all configured scopes.

👎 Actual Behavior with Screenshots

The authorize URL uses prompt=none → LinkedIn silently returns only previously-consented scopes (none on a first connect). The callback returns a valid code, but Postiz rejects it with "Not enough scopes, when choosing a provider, please add all the scopes." No consent screen is ever shown, so the org/member scopes can never be granted through the UI. "Permitted services" in LinkedIn account settings is empty (nothing to revoke/reset). Tried normal window and incognito — same result.

💻 Operating system

Linux

🤖 Node Version

v22.20.0

📃 Provide any additional context for the Bug.

• Postiz version: v2.21.8 (self-hosted, Docker, Temporal-based stack)
• Reverse proxy: Cloudflare Tunnel → host:5105
• Facebook, Instagram and TikTok connect fine with the same setup – only LinkedIn fails.

👀 Have you spent some time to check if this bug has been raised before?

• I checked and didn't find similar issue

Are you willing to submit PR?

None

[parthguru]

Confirming this on a self-hosted instance, with a working fix.

Root cause — two compounding problems:

1. generateAuthUrl() in both linkedin.provider.ts and linkedin.page.provider.ts uses prompt=none. That forces silent authorization, so LinkedIn only returns
   scopes the user previously consented to. On a first-time connect there's no prior consent → the token comes back missing scopes → checkScopes() throws
   NotEnoughScopes → social-connect returns 400.
2. The personal LinkedinProvider also requests org scopes (rworganizationadmin, rorganizationsocial, worganizationsocial) that need Community Management
   API / Advertising API access (legal-entity verification). LinkedIn rejects the entire OAuth request if any requested scope is unauthorized — so individual users
   can't connect even a personal profile, even though wmembersocial alone is enough for personal profile posting.

Fix that works (personal profile, no org API access required):

• In linkedin.provider.ts: change prompt=none → prompt=consent, and reduce scopes to ['openid', 'profile', 'wmembersocial'].
• Leave linkedin.page.provider.ts with the full org scopes (company-page posting legitimately still needs Community Management API approval).

This is essentially the scope decoupling proposed in #1134 (closed unmerged), combined with the prompt=none → prompt=consent change. With both, personal LinkedIn
connects cleanly. Would be great to land this so self-hosters don't have to patch the image.

[SCR-RESEARCH]

SCR Research New Information: We can confirm this reproduces on v2.10.1 and have a working fix to share, with a diagnostic trail that might help pin down the actual mechanism.
Confirmed via browser DevTools (Network tab, Preserve log): when prompt=none is set and no prior LinkedIn authorization exists for the app, the browser lands on LinkedIn's generic error page (https://www.linkedin.com/oauth/v2/authorization?...) before any request ever reaches Postiz's backend — confirmed no corresponding log entry on the Postiz side at all. So this isn't a Postiz-side callback failure, it's LinkedIn rejecting the authorize request outright because there's nothing to silently re-authorize on a first-time connect.
Fix that worked for us: changing prompt=none → prompt=consent in the compiled linkedin.provider.js (all three process copies — backend, workers, cron each bundle their own copy of the shared lib). After that change, the real LinkedIn consent screen appears as expected.
One thing worth flagging for anyone else debugging this: on v2.10.1 (predates #1134), fixing prompt=none alone surfaced a second, separate bug — the personal-profile provider's scopes array still includes the four org-level scopes (r_basicprofile, rw_organization_admin, w_organization_social, r_organization_social), which a personal-profile-only app isn't approved for, producing unauthorized_scope_error. That one's already fixed upstream via #1134 for anyone on a current version — but if you're on an older image like we were, you may need both fixes together, not just this one. Wanted to flag in case it saves someone a second round of debugging thinking their prompt fix didn't work when actually a second, already-fixed-elsewhere bug was masking success.
Happy to share the exact patch/compose approach if useful — went with a bind-mounted corrected file rather than a live sed-patch so it survives redeploys cleanly.