[BUG] Replace cookie-based auth with OAuth2 + persistent session storage

[5queezer]

Problem

The upstream stickerdaniel/linkedin-mcp-server uses browser cookie extraction for authentication. This breaks in serverless environments (Cloud Run, Lambda) because:

1. Cold starts kill sessions. Cookies are stored in-process memory. When the container scales to zero and back, auth is gone.
2. Re-login required every time. The --login flag triggers a browser-based flow that can't run headless in a container.
3. No multi-user support. One cookie jar = one LinkedIn account. No way to serve multiple users from a single deployment.

Error from upstream server:

Authentication failed. Run with --login to re-authenticate.
Runtime: linux-amd64-container

Proposed solution

1. OAuth2 authentication flow

Replace the cookie-based login with LinkedIn's official OAuth 2.0 flow:

• Redirect user to LinkedIn authorization URL
• Receive callback with auth code
• Exchange for access token + refresh token
• Store tokens (not cookies) persistently

LinkedIn OAuth scopes needed:

• r_liteprofile (basic profile)
• r_emailaddress (email)
• w_member_social (posting, if needed later)
• Messaging API: requires LinkedIn Marketing/Compliance API partnership or Community Management API access. Check current availability.

Blocker to investigate: LinkedIn's messaging API (/messaging/conversations) is not available via standard OAuth apps. It requires either the Compliance API (enterprise) or scraping. Evaluate whether the existing scraping approach can be kept but with persistent cookie storage as a middle ground.

2. Cookie bucket storage (GCS)

If OAuth messaging access is not feasible, keep the cookie-based approach but persist cookies externally:

• On successful login, serialize cookies to JSON
• Upload to a GCS bucket (one file per user, keyed by LinkedIn username or hash)
• On cold start, check bucket for valid cookies before requesting re-login
• TTL: LinkedIn session cookies typically last 1-6 months
• Encrypt at rest (GCS default encryption or customer-managed keys)

gs://linkedin-mcp-cookies/
  {user_hash}/
    cookies.json.enc
    metadata.json  # last_refreshed, expires_at

3. Cloud Run deployment

• Host as Cloud Run service with --min-instances=0 (scale to zero for cost)
• Auth via Cloud Run IAM or API key for the MCP client
• Health check endpoint: GET /health returns cookie freshness status
• Login endpoint: GET /auth/login triggers OAuth or cookie refresh flow

4. Message reading support

Extend the MCP server with:

• get_inbox(limit) - list recent conversations (already exists upstream but broken)
• get_conversation(thread_id) - read full thread
• search_conversations(keywords) - keyword search
• mark_as_read(thread_id) - optional

Ensure message parsing handles:

• InMail vs regular messages
• Group conversations
• Attachments / link previews (metadata only)

Tasks

• Fork setup: Cloud Run Dockerfile, service config, IAM
• Investigate LinkedIn messaging API access via OAuth (is it even possible without enterprise partnership?)
• If no OAuth messaging: implement GCS cookie bucket persistence
• Add /auth/login endpoint with callback handler
• Add /health endpoint reporting session validity
• Test cold start recovery (scale to zero, wait, call get_inbox)
• Test session expiry handling (graceful re-auth prompt vs crash)
• Wire up as MCP server for Claude.ai integration

Context

This fork exists because the upstream server fails in Claude.ai's MCP integration. The server connects but auth drops on every cold start, making it unusable for daily workflows. The goal is a self-hosted, persistent LinkedIn MCP server that survives container restarts and serves one user reliably from Cloud Run at near-zero cost (same pattern as Nexus CRM deployment).

References

• Upstream: github.com/stickerdaniel/linkedin-mcp-server
• LinkedIn OAuth docs: https://learn.microsoft.com/en-us/linkedin/shared/authentication/authorization-code-flow
• LinkedIn Messaging API status: https://learn.microsoft.com/en-us/linkedin/compliance/
• GCS client library: @google-cloud/storage

[5queezer]

Audit complete.

Findings:

1. LinkedIn OAuth does not solve messaging for this project.

   • The repo currently has OAuth only for protecting the MCP endpoint exposed to clients like Claude, not for LinkedIn auth itself.
   • LinkedIn’s public OAuth docs cover member authorization for standard scopes like r_liteprofile, r_emailaddress, and w_member_social, but not general inbox/message access.
   • LinkedIn’s Compliance APIs are for regulated/partner archival use and Sales Navigator compliance events, not a drop-in replacement for consumer messaging inbox access.

2. Current repo architecture already points to the right fallback: persist the browser-derived auth state, not LinkedIn API tokens.

   • The fork already stores source auth state under ~/.linkedin-mcp/ and bridges that into foreign/container runtimes.
   • Current persistence is local filesystem only, so Cloud Run cold starts still lose state unless a volume is mounted.

3. Fastest path for issue [BUG] Replace cookie-based auth with OAuth2 + persistent session storage #7: add pluggable external auth-state storage, with GCS as the first backend.

   • Persist the full auth root (~/.linkedin-mcp/), not only cookies.json.
   • Restore from GCS before auth checks/browser startup.
   • Re-sync to GCS after --login, after source-state changes, and on shutdown after cookie export.

Proposed implementation shape:

• Add config:
  • AUTH_STORAGE_BACKEND=local|gcs
  • AUTH_STORAGE_GCS_BUCKET
  • AUTH_STORAGE_GCS_PREFIX
• Add linkedin_mcp_server/auth_storage.py
  • sync_from_remote_if_configured()
  • sync_to_remote_if_configured()
  • archive/extract the auth root as a tar.gz snapshot
• Hook sync points into:
  • startup before get_authentication_source()
  • post-login after write_source_state()
  • shutdown after cookie export in close_browser()
  • logout/clear path to delete remote snapshot too
• Keep existing MCP OAuth as-is for connector auth.

Notable repo facts supporting this:

• README already documents that current remote deployment OAuth is only for protecting the MCP endpoint and that OAuth state is in-memory.
• cli_main.py skips LinkedIn profile checks when MCP OAuth is enabled, which confirms those are separate concerns.
• drivers/browser.py and session_state.py already centralize source/runtime auth artifacts, so a storage backend can be added without touching the scraping tool surface.

Blocked items:

• I did not push code yet because the GitHub connector available here is sufficient for reading and issue/PR operations, but not practical for safely editing multiple existing files in this repo without full tree/content update support.
• No evidence from official LinkedIn docs that standard OAuth gives this project inbox/message-read parity.

References:

• Repo issue [BUG] Replace cookie-based auth with OAuth2 + persistent session storage #7
• README.md
• linkedin_mcp_server/cli_main.py
• linkedin_mcp_server/drivers/browser.py
• linkedin_mcp_server/session_state.py
• LinkedIn OAuth overview: https://learn.microsoft.com/en-us/linkedin/shared/authentication/authentication
• LinkedIn native OAuth / PKCE doc: https://learn.microsoft.com/en-us/linkedin/shared/authentication/authorization-code-flow-native
• LinkedIn Compliance overview: https://learn.microsoft.com/en-us/linkedin/compliance/compliance-sales-nav/overview