LinkedIn OAuth shows different sign-in options (Google/Apple SSO) depending on browser - is this expected behavior?

[MiguelAngelGarciaGomez]

Description

While implementing LinkedIn OAuth using NextAuth.js, I noticed that LinkedIn's OAuth sign-in popup displays different authentication options depending on the browser being used. I'd like to understand if this is expected behavior and what causes it.

Observed Behavior

When users click "Sign in with LinkedIn" in my app, they're redirected to LinkedIn's OAuth authorization page. However, the sign-in options displayed vary by browser:

Browser	LinkedIn OAuth Sign-In Options
Chrome	Shows "Continue with Google" + "Sign in with Apple" + Email/Password
Safari	Email/Password only
Firefox	Email/Password only
Brave	Email/Password only

My NextAuth Configuration

LinkedInProvider({
  id: 'linkedin',
  clientId: process.env.LINKEDIN_CLIENT_ID!,
  clientSecret: process.env.LINKEDIN_CLIENT_SECRET!,
  authorization: {
    params: {
      scope: 'openid profile email w_member_social'
    }
  },
  wellKnown: undefined,
  client: {
    token_endpoint_auth_method: 'client_secret_post'
  }
})

Environment

• NextAuth.js version: 4.24.11
• Next.js version: 14.2.28
• Browser versions tested:
  ** Chrome (latest)
  ** Safari (latest)
  ** Firefox (latest)
  ** Brave (latest)

Questions

1. Is this browser-dependent behavior expected? Is LinkedIn detecting browser capabilities and showing different options accordingly?
2. Is this related to third-party cookie restrictions? Safari, Firefox, and Brave have stricter privacy protections. Could this be why Google/Apple SSO options don't appear in those browsers?
3. Does the FedCM API play a role here? Chrome supports the Federated Credential Management API. Could LinkedIn be using this to offer Google Sign-In only in Chrome?
4. Is there anything in the NextAuth OAuth flow that could influence this? Or is this entirely controlled by LinkedIn's authorization server?
5. Has anyone else observed similar behavior with other OAuth providers?

Additional Context

• The OAuth popup is opened via NextAuth's standard signIn('linkedin') flow
• The redirect URL and OAuth parameters are identical across all browsers
• This appears to be LinkedIn's server-side decision, not something controlled by NextAuth

Screenshots

Brave

Chrome

Safari

Firefox

[Jamonygr]

From your description, the LinkedIn-hosted login UI that appears during the OAuth authorize step shows Google/Apple “shortcut” sign-in in Chrome, but falls back to email/password only in Safari/Firefox/Brave. That aligns with how many identity pages adapt based on browser privacy features / blocked third-party resources / feature detection rather than anything in your OAuth request.
GitHub

1. Is the browser-dependent behavior expected?

Yes. The page you’re looking at is LinkedIn’s own login/authorization experience (their domain, their frontend). Providers commonly A/B test and feature-detect to decide which sign-in options to render (and they’ll change it without notice). NextAuth isn’t rendering that page; it’s just redirecting the user there.
GitHub

Also, LinkedIn explicitly supports “Continue with Google” as a sign-in method, but they don’t guarantee it appears in every context/browser.
LinkedIn

2. Is this related to third-party cookie restrictions / privacy protections?

Very possibly, yes — especially for anything that relies on embedded Google/Apple components (iframes, silent auth, one-tap, etc.).

Safari (ITP) blocks third-party cookies by default, and third-party cookie access generally requires special mechanisms like the Storage Access API (or popup compatibility behavior).
WebKit

Brave blocks third-party cookies by default.
Brave Help Center

Firefox can block third-party cookies in stricter modes and has tracking protections that can interfere with third-party identity widgets.
Mozilla Support
+1

Even though the LinkedIn login page is first-party to linkedin.com, the Google/Apple sign-in options often involve loading third-party resources from google.com / apple.com. If those resources are blocked (cookies, storage, scripts, trackers), LinkedIn may:

hide those buttons entirely, or

fail to render them (e.g., the UI is injected by scripts that don’t load), or

choose a safer fallback (email/password) to reduce broken sign-in attempts.

A good “proof” test: in Firefox/Brave/Safari, temporarily disable tracking protection/content blockers for linkedin.com and see if the buttons come back.

3. Does FedCM play a role?

It could — but only on LinkedIn’s side. FedCM exists specifically to support federated identity flows in a world where third-party cookies are restricted. Chrome positions FedCM as enabling federated sign-in even when third-party cookies are unavailable.
Chrome for Developers
+1

Google’s identity stack has moved toward FedCM to reduce reliance on third-party cookies.
Google for Developers
+1

So if LinkedIn implements Google sign-in using a mechanism that works best in Chrome (potentially FedCM-backed), that might explain “Chrome shows it, others don’t.” But: you can’t confirm this from NextAuth, and NextAuth is not involved in that “Continue with Google” UI at all.

4. Can anything in the NextAuth OAuth flow influence this?

Practically: no. NextAuth is sending the user to LinkedIn’s authorization endpoint with your params (scope, redirect URI, etc.). Your config doesn’t tell LinkedIn which login buttons to display.
GitHub

There are only a few indirect things that might change the page variant (still under LinkedIn’s control), like:

whether the user already has linkedin.com cookies / is partially signed in,

whether the popup vs full-page redirect is used,

whether LinkedIn recognizes the client or user as part of an experiment cohort.

But none of these are knobs you can reliably set in NextAuth to “force Google/Apple buttons to appear.”

5. Have others observed similar behavior with other OAuth providers?

Yes — it’s common. Many providers tailor the login page by browser:

privacy mode / tracking protection on/off,

third-party cookie availability,

JS execution constraints,

“embedded in popup” vs “top-level navigation,”

A/B tests and rollout buckets.

What you can do (actionable)

Treat it as provider UI variance. Don’t try to “fix it” in NextAuth; there’s nothing to configure there for LinkedIn’s UI.
GitHub

Reproduce cleanly:

test in private/incognito with no extensions

clear linkedin.com site data

compare opening https://www.linkedin.com/uas/login directly vs coming through your OAuth popup

Check what’s blocked (DevTools → Console/Network) in Brave/Firefox/Safari for failed/blocked loads to Google/Apple domains.

If you need a consistent UX, the only “consistent” layer you control is your own sign-in page (e.g., explain “Use email/password on LinkedIn if Google/Apple isn’t offered in your browser”).

If you paste the exact LinkedIn authorize URL NextAuth generates in each browser (with query params), I can sanity-check that it’s identical and point out anything that could push LinkedIn into a different rendering path — but the core answer remains: this is LinkedIn’s login UX + browser privacy differences, not a NextAuth issue.