Deep Dive - Authentication Architecture

The Cursor JD leads with authentication. An EM for Core Services is expected to reach for the right OAuth flow without thinking, then explain the trade-off out loud while a peer pokes holes in it.

Start by separating two specs that interviewers love to conflate. OAuth 2.0 is an authorization framework: it answers "can this client act on this resource on the user's behalf," and it hands back access tokens. OIDCOpenID Connect. A modern standard that powers single sign-on, built on OAuth. is a thin identity layer on top of OAuth that adds an ID token - a signed JWT that says "this is who the user is." You ask OAuth for permission to call an API; you ask OIDC who just logged in.

Flow selection is a function of one question: can the client keep a secret? A backend service can. A desktop editor or a single-page app cannot, because anything shipped to a user's machine can be extracted.

Why PKCE and why not implicitthe public-client story

Cursor's editor is a native app that talks to backend services and to SCM providers like GitHub. It has no safe place to store a client secret, so it uses Authorization Code + PKCE. The client generates a random code_verifier, sends its SHA-256 hash (code_challenge) on the authorize request, then proves possession of the verifier when redeeming the code. An attacker who intercepts the authorization code on the redirect cannot exchange it without the verifier.

code_verifier  = random(64)                 // kept in memory on the client
code_challenge = base64url(sha256(code_verifier))

// 1. authorize:  ?code_challenge=...&code_challenge_method=S256
// 2. user logs in -> redirect back with ?code=...
// 3. token:      POST { code, code_verifier }   // server recomputes the hash

The implicit flow returned tokens straight in the redirect URL fragment, where they leaked into browser history, referrer headers and logs. It is deprecated; PKCE replaced it for browser clients. If an interviewer asks why you avoided implicit, that is the whole answer and naming it signals you track the spec rather than copying a 2016 tutorial.

Constraining blast radiusredirect URIs and scopes

• Exact-match redirect URIs. Register the precise callback; reject wildcards and open redirects. A loose redirect turns PKCE's protection into theater because the code goes to the attacker's URL.
• Least-privilege scopes. A token that can only read one repo is a smaller breach than one that can write to every org the user belongs to. Scope is your blast-radius dial.
• `state` parameter. A random, verified state ties the callback to the request you started and blocks CSRF on the redirect.

Where enterprise SSO and SCIM fitthe B2B reality

Enterprise buyers will not let Cursor own their employees' passwords. They federate: the user logs in at their own IdP (Okta, Entra, Google Workspace) over OIDCOpenID Connect. A modern standard that powers single sign-on, built on OAuth. or SAMLAn enterprise standard that powers single sign-on. and Cursor trusts the assertion. SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. runs alongside as the provisioning channel - when HR deboards someone, SCIM deprovisions the Cursor account automatically rather than waiting for a token to expire.

This is where interviewers find out whether you have the "strong opinions on reliability and performance" the JD asks for. The JWT-versus-session decision is a tax you pay on every single request at 1M+ DAU.

The core tension is stated in one line: JWTs are stateless and verify locally, so they scale beautifully, but you cannot easily un-issue one before it expires. Server-side sessions revoke instantly, because the truth lives in your store, but every request pays a lookup.

The compromise everyone actually shipsshort access + long refresh

Production auth rarely picks a pure side. The standard pattern: a short-lived access JWT (5–15 minutes) for the hot path, a long-lived refresh token (days to weeks) held more carefully and a revocation check that runs only at refresh time.

1. 1Issue. On login, mint an access JWT (~10 min) plus a refresh token tied to a server record.
2. 2Serve. Verify the access JWT locally on every request - no DB hit, this is the throughput win.
3. 3Refresh. When it expires, the client trades the refresh token for a new access JWT; this is the moment you check revocation and a token_version.
4. 4Revoke. Bump the user's token_version or delete the refresh record; within one access-token TTL, all their tokens stop refreshing.

That token_version (or session_epoch) column is the trick that buys you near-instant revocation without paying for a lookup on every request. You accept a bounded staleness window equal to the access-token lifetime - make it short and that window is minutes, not days.

JWT failure modes to name unpromptedthe security-credibility checklist

Two more that bite at scale: tokens that never set exp and signing keys that are short, hand-rolled or shared across environments. A leaked HS256 secret lets anyone forge tokens for everyone, which is why asymmetric RS256/ES256 with a private signing key is the default at a 1M-user tool.

Authentication proves who is calling. Authorization decides what they're allowed to do. The JD's auth ownership is mostly the second one and it's where B2B dev-tool design gets genuinely hard.

Keep the two layers clean. The access token tells you the principal; a separate, centralized authorization decision tells you whether that principal may read this repo or invite that member. Bleeding authz logic into every service is how a flat org ends up with seven inconsistent permission checks and a security incident.

RBAC for a B2B toolthe org / team / role spine

Cursor is sold to organizations, so the model has tenancy baked in. A user belongs to one or more orgs; an org has teams; roles attach at the org or team level and grant permissions.

Where pure RBAC breaks: resource-level accessand why ReBAC enters

Roles answer org-wide questions well and resource-specific questions badly. "Can Maya read repo X" is not a role - it's a relationship between a user and one resource and modeling every such grant as a role explodes into role sprawl. This is the case for ReBAC (relationship-based access control), the Google Zanzibar model behind tools like SpiceDB and OpenFGA.

For Cursor specifically, repo and agent-workspace access is the relationship-heavy part, so a Zanzibar-style layer for resource sharing on top of plain RBACRole-Based Access Control. Granting permissions by role rather than configuring each person individually. for org roles is a defensible answer. Frame it as general-industry practice - you don't need to claim Cursor runs OpenFGA, only that the resource-sharing shape calls for ReBAC thinking.

Machine clients, scopes and auditthe parts juniors forget

• Service accounts get their own role model. A CI bot is not a person with a person's role; give it a machine principal with least-privilege scopes and no interactive session.
• Token scopes enforce least privilege per-credential. Even an admin's token, when minted for a read-only task, should carry read-only scope. Scope narrows the breach when a single token leaks.
• The authz path must be fast and centralized. A check on every product surface that disagrees with the others is a contract bug; a shared decision service (or shared library + cache) is the fix and it's a service-contract problem, not a feature.
• Audit every authz decision. "Who accessed what, when and was it allowed" is both an incident-response tool and a hard requirement in enterprise security reviews. Logging only denials is not enough; sales will ask for the allows too.

Auth that's secure on launch day and never rotates a key is auth waiting for a breach. The lifecycle - keys, refresh tokens, secrets and a breach plan - is what separates an EM who has operated auth from one who has only diagrammed it.

Key rotation with overlapping validityJWKS and the kid header

You rotate signing keys regularly, but you can't flip them atomically across a fleet - tokens signed with the old key are still in flight. The answer is overlap: publish both keys, sign new tokens with the new key and keep verifying old tokens until they age out.

1. 1Publish. Expose a JWKS endpoint listing current public keys, each tagged with a kid (key id).
2. 2Add the new key. Add key B to JWKS alongside key A; verifiers can now check tokens signed by either.
3. 3Cut over signing. Start signing new tokens with key B; the token's kid header tells verifiers which to use.
4. 4Drain. Wait one max token lifetime so every key-A token has expired.
5. 5Retire. Remove key A from JWKS. No token in existence references it anymore.

The kid header is what makes this integrated - the verifier reads it, fetches the matching key from JWKS and never has to guess. Clients cache JWKS, so set a sane cache TTL and they pick up new keys without a deploy.

Refresh-token rotation with reuse detectioncatching theft

Every time a refresh token is redeemed, issue a new one and invalidate the old. If the old one is ever presented again, you have a problem: either the legitimate client or a thief is replaying it and you can't tell which - so you revoke the whole token family and force re-login.

Revocation: pick your latencyimmediacy vs hot-path cost

For most of Cursor's traffic, short TTLs plus a token_version check are enough. Reserve an immediate deny-list for the high-stakes cases - a confirmed compromised account, an emergency "log this person out now" - where a few minutes of staleness is unacceptable.

Secrets and the breach planthe operational half

• Signing keys never ship to clients. A public client verifies nothing with a private key; it only holds short-lived tokens. Private keys live in a KMS or secrets manager, scoped to the issuing service.
• SCM provider credentials rotate too. The GitHub/GitLab app secrets and webhook signing secrets your integrations depend on are secrets like any other - put them on a rotation schedule and store them in the same vault.
• Know your blast radiusHow much breaks if a change goes wrong; the scope of potential damage. before the breach. Have an answer to "how fast can we invalidate everything and what breaks when we do." Rotating the signing key logs out every user; bumping all token versions does the same. Practice it so the answer in the incident is muscle memory, not a debate.

Time to assemble the pieces into one design you can present and defend. This is the shape the system-design deep-dive takes and rehearsing it end to end is how you walk in with a structure instead of improvising under pressure.

Open by restating constraints and naming the flow, so the panel knows you've placed the problem: public native client, 1M+ DAU, auth on every request, multi-tenant orgs, third-party SCM. Then march through the lifecycle.

1. 1Login. Authorization Code + PKCE in the system browser; exact-match redirect, state for CSRF, least-privilege scopes. Enterprise tenants federate to their IdP over OIDCOpenID Connect. A modern standard that powers single sign-on, built on OAuth./SAMLAn enterprise standard that powers single sign-on..
2. 2Issuance & storage. Mint a short-lived access JWT (~10 min, RS256) plus a refresh token. Store tokens in the OS secure storage (Keychain / Credential Manager / libsecret), never plaintext on disk.
3. 3Serve requests. Verify the access JWT locally on the hot path - no per-request DB hit. Claims carry user id, org and coarse role.
4. 4Refresh & revoke. Rotate refresh tokens with reuse detection; check token_version at refresh so revocation lands within one access TTL. Keep a deny-list for emergency log-out-now.
5. 5Authorize. RBACRole-Based Access Control. Granting permissions by role rather than configuring each person individually. for org/team roles in claims; a ReBAC layer for per-repo sharing. SCM access uses separately-scoped OAuth tokens to GitHub/GitLab, stored and refreshed independently.
6. 6Rate limit. Throttle token and refresh endpoints per client and per IP; auth endpoints are a favorite target for credential stuffing.

The reliability storyauth is on every request

Because authentication sits on the hot path of a 1M-user product, its availability is the product's availability. Lead the reliability section with that and the trade-offs follow naturally.

The security surfacename the attacks, name the mitigation

Close with the service contractthis is the EM differentiator

An IC stops at the design. An EM for Core Services closes with the contract: what guarantees this layer exposes to the product teams who build on it and how it changes them without breaking everyone.

• What we expose. A token-verification primitive (local, microsecond-fast), an authz-decision API and a documented claim shape. Product teams never reimplement auth.
• Our guarantees. A stated availability SLO for token issuance, a verification latency budget and a maximum revocation-propagation window so callers know how stale a permission can be.
• How we version. Additive claim changes are backward-compatible; breaking changes ship behind a new claim version with an overlap window and contract tests, the same overlap discipline as key rotation.