LinkedIn Professional Network  ·  View 28 of 30  ·  7 · Assurance

Identity and Access Flow

Who proves what to whom at sign-in, and how a session becomes a principal that services trust.

Editable source SVG draw.io All views
Member Client app Edge Identity ATO risk Credential store API layer Rest.li service 1. email + password 2. POST /login 3. rate + bot check 4. forward 5. verify hash 6. device, IP, velocity 7. new device: step up 8. MFA challenge 9. passkey or TOTP 10. second factor 11. session + short token 12. GET /v1/feed + token 13. verify signature, expiry 14. principal over mTLS 15. 401 on expiry: refresh Identity and Access — Sign-in with Step-up Sign in with LinkedIn for third parties is the OAuth 2.0 / OIDC variant of steps 11 to 14. v 1.0 · owner Security Architecture · date 2026-09

Decisions

  • Passwords are stored with an adaptive salted hash (argon2id). LinkedIn's 2012 breach exposed unsalted SHA-1 hashes, the textbook case for this rule (widely reported)
  • Step-up is risk-based: MFA is required for a new device, an unusual IP or unusual velocity, not on every login
  • Access tokens are short-lived; refresh tokens rotate and are bound to the device

Standards

  • OAuth 2.0 and OIDC for Sign in with LinkedIn, with scopes consented per app
  • SAML for enterprise recruiter seats
  • Passkeys are accepted as a first factor

Risks

  • A SIM swap defeats SMS codes. SMS is the weakest factor and is not offered on privileged seats
  • A revoked session must stop working in every colo within seconds, so revocations travel as Kafka events