Auth & Identity

Busted

• Access token vs. refresh tokenTwo keys with different jobs: a short-lived one that opens API calls, and a long-lived one whose only job is minting more of the first.
• Account linkingOne person, several sign-in methods, one account. The rules that decide whether 'Continue with Google' joins an existing user or makes a twin.
• Account recoveryThe fallback paths that let someone regain an account after losing a password, phone, passkey, inbox, or other login proof.
• Age assurance and identity proofingChecking whether someone is old enough or matches a real-world identity, while collecting only the evidence the decision actually needs.
• Anonymous / guest userA temporary but usable account that saves someone's work before signup and becomes their real account when they add a login.
• API keyA long random string that lets one program call another as your account. No login screen, no user, just the secret.
• Attribute-based access control (ABAC)Permissions decided from facts like department, ownership, region, amount, or time instead of only a fixed role name.
• Audit log (auth events)A security history of logins, failed attempts, role changes, token grants, and other events that answer who did what and when.
• Auth guard / protected routeThe code gate in front of a page or endpoint that bounces anyone without a valid session to the login screen.
• Authentication vs. authorizationAuthentication proves who you are. Authorization decides what you're allowed to do once you're in. 401 versus 403.
• Authorization Code Flow with PKCEThe OAuth flow for apps that cannot keep a secret: the client proves it started the login with a one-time hash, so a stolen code is useless.
• Bearer tokenA token that works like cash: whoever holds it gets the access, and the server never asks how they got it.
• Client ID and client secretThe client ID publicly names your OAuth app; the client secret proves the server is that app and must stay off browsers and mobile apps.
• Consent screen / scopesThe 'this app wants to access your...' page, and the named permissions (scopes) it is asking you to approve.
• Cookie flags (HttpOnly, Secure, SameSite)The attributes on a Set-Cookie header that decide who can read it, whether it travels unencrypted, and which sites can send it back.
• Domain verification and domain-based enrollmentA company proves it owns acme.com, then people with verified @acme.com addresses can find or join its workspace automatically.
• Email address verificationMailing a one-time link or code to a new signup and only trusting the address once they click it back.
• Global sign-outThe security button that ends every active login for an account, including sessions on phones and browsers you cannot reach.
• Hardware security keyA physical USB or NFC key you tap at login, proving the real device is present without giving a phishable code to type.
• ID tokenThe signed token from OpenID Connect that tells your app who just authenticated, while an access token says what may call an API.
• Identity federationTrusting another organization to authenticate its people, so they can use your app with accounts controlled by their own IT.
• Identity provider (IdP)The system that actually holds the accounts and vouches for who a user is, so your app can trust its answer instead of storing passwords.
• Impersonation (login as user)A controlled support session that lets staff see the product as a user while preserving who the staff member really is.
• Invite flowA pending place in a workspace that becomes a real membership when the invited person verifies who they are and accepts.
• Just-in-time (JIT) provisioningThe user's account is created automatically the first time they sign in through the company's SSO.
• JWT (JSON Web Token)A signed, self-contained token: three base64 chunks separated by dots, carrying claims about a user that anyone can verify without a lookup.
• Machine-to-machine auth (client credentials)One service proves its own identity to another and gets limited API access, with no human login or user account involved.
• Magic linkLogging in by clicking a one-time link emailed to you. Owning the inbox is the whole password.
• mTLS (mutual TLS)TLS where the client shows a certificate too, so both services prove their identity before any request is accepted.
• Multi-factor authentication (MFA)Requiring two or more different kinds of proof at login, so one stolen credential on its own does not get anyone in.
• OAuth 2.0The handshake that lets one app act on your account at another app, without ever seeing your password.
• OAuth redirect URI / callback URLThe exact, pre-registered URL where an OAuth provider sends the browser after the person approves or cancels access.
• OAuth state parameterA random value sent out and checked on return so an OAuth callback belongs to the same browser login attempt.
• One-time password (OTP)A short code meant to work once, delivered by email or SMS or generated by an authenticator app.
• OpenID Connect (OIDC)An identity layer on top of OAuth. OAuth grants permission to call an API; OIDC returns a signed ID token that says who just logged in.
• Organization / workspace membershipUsers belong to teams, and permissions live on the membership rather than the person. One login, different roles in different workspaces.
• PasskeyA login key stored on your phone or laptop, unlocked with a face, fingerprint, or PIN. Nothing to type, nothing to phish.
• Password hashing (bcrypt/argon2)Storing a slow, salted one-way scramble instead of the password. Nobody can read it back, but a login attempt can still be checked.
• Password reset flowThe forgot-password path: an emailed one-time link that expires, lets you set a new password, then stops working.
• Passwordless authenticationAny sign-in that skips the password: emailed links, one-time codes, or passkeys carry the proof instead.
• Permission / policy engineOne service that answers 'may this user do this to that resource?' so every API follows the same permission rules.
• Recovery codesSingle-use backup codes saved when you enable MFA, so losing your phone or security key does not permanently lock you out.
• Refresh tokenThe long-lived credential your app quietly trades for a new access token, so people stay signed in without logging in again.
• Refresh-token rotation and token revocationEach refresh burns the old token for a new one, so a replayed copy trips the alarm and the whole session family gets killed.
• Relationship-based access control (ReBAC)Permissions that follow relationships like owner, member, parent, or shared-with, so access can inherit through a graph.
• Role-based access control (RBAC)Permissions bundled into named roles like admin, editor, viewer, so people get a role instead of a pile of individual checkboxes.
• SAMLThe XML-based login protocol many large companies use to let employees enter your app with their work account.
• SAML service provider and OIDC relying partyTwo protocol names for your app when it trusts another system to log users in: service provider in SAML, relying party in OIDC.
• SCIMThe standard that lets company IT automatically add, update, group, and disable users in your app from its directory.
• Service accountA named account for software, so a job or service gets its own permissions and audit trail instead of borrowing a human login.
• SessionThe record that keeps someone logged in between requests: a random ID in a cookie pointing at their login state on the server.
• Session timeoutThe rule that ends a login after enough time passes, counted either from the last action (idle) or from sign-in (absolute).
• Silent refreshRenewing a login in the background before its short-lived token expires, so the person keeps working without another prompt.
• Single Sign-On (SSO)One company login opens every app the company uses, so nobody keeps a separate password per tool.
• Social loginSigning up with a Google, GitHub, or Apple account you already have, instead of creating one more password.
• Step-up authenticationAsking for fresh, stronger proof right before a risky action, even though the person is already logged in.
• Time-based one-time password (TOTP)The 6-digit code an authenticator app regenerates every 30 seconds, computed from a secret the app and the server both hold.
• Trusted device recognitionThe 'remember this device' option that skips repeat MFA on a known browser for a limited time, while risky actions still ask.
• WebAuthnThe browser standard behind passkeys and security keys: a site verifies a signed challenge without ever receiving the private key.

The territory

29 core terms mapped for this field, ranked by how often builders reach for them. Each one is a future entry. Want to bust one? One entry, one file, one pull request.

• OAuth 2.0delegated access protocol letting an app act on your behalf"OAuth" · "the permission handshake" · "let my app use their account"
• Single Sign-On (SSO)one login unlocks many apps across an organization"log in once for everything" · "company-wide login"
• Social loginsign in using an existing Google/GitHub/Apple account"that Continue with Google button" · "log in with Facebook"
• Magic linkpasswordless login via emailed one-time URL"email me a login link" · "no password, just click the email"
• Passkeyphone/laptop biometric replaces password, phishing-resistant"log in with FaceID instead of a password" · "the fingerprint login thing"
• Passwordless authenticationsigning in without a password: links, codes, or passkeys"get rid of passwords" · "no password login"
• Multi-factor authentication (MFA)second proof beyond password before access granted"2FA" · "the code from my phone" · "two-step login"
• Time-based one-time password (TOTP)6-digit code rotating every 30 seconds from a shared secret"authenticator app code" · "the Google Authenticator numbers" · "the code that keeps changing"
• Sessionserver-remembered login state tied to a cookie"staying logged in" · "the thing that expires and logs me out"
• Session timeoutlogin state expiring after elapsed or idle time"logged out for being idle" · "how long should logins last"
• Cookie flags (HttpOnly, Secure, SameSite)settings that stop scripts and sites from stealing sessions"make the cookie safe" · "the cookie settings nobody explains"
• JWT (JSON Web Token)signed self-contained token carrying user claims"that long random string in the header" · "the token my API checks"
• Bearer tokenwhoever holds the token gets the access"the Authorization header thing" · "paste the token to call the API"
• Refresh tokenlong-lived credential that silently mints new access tokens"so users don't get logged out" · "the thing that renews my login"
• Access token vs. refresh tokenshort-lived key for calls, long-lived key for renewal"why do I have two tokens"
• Refresh-token rotation and token revocationreplacing tokens on use and invalidating leaked ones"kill the stolen token" · "make old tokens stop working"
• Authentication vs. authorizationwho you are versus what you're allowed to do"logged in but not allowed" · "authn vs authz"
• Role-based access control (RBAC)permissions granted by named roles like admin/editor/viewer"admin vs regular user" · "permission levels"
• Organization / workspace membershipusers belonging to teams with per-team roles"invite teammates to my account" · "team accounts"
• Identity provider (IdP)the system that vouches for who a user is"whoever actually stores the logins"
• OpenID Connect (OIDC)identity layer on top of OAuth, returns an ID token"OAuth but for actually knowing who they are"
• Authorization Code Flow with PKCEsecure OAuth flow for browser and native apps"the safe OAuth flow" · "pixie" · "why my SPA login broke"
• Password hashing (bcrypt/argon2)one-way scrambling so stored passwords can't be read"never store the real password" · "the scrambled password"
• Account linkingmerging multiple sign-in methods into one user identity"same email, different login buttons" · "duplicate account problem"
• Email address verificationconfirming ownership of an address before granting access"the confirm your email step"
• Password reset flowtokenized, expiring path to set a new password"forgot password" · "the reset link"
• API keystatic secret identifying a machine caller, not a human"the string I paste in the settings" · "the developer token"
• Consent screen / scopesthe permission list a user approves during OAuth"this app wants access to..." · "the checkbox permissions page"
• Auth guard / protected routecode gate redirecting unauthenticated visitors to login"make this page members-only" · "kick them to the login page"

Deeper in the field

• SAML XML-based enterprise SSO protocol demanded by big customers
• SCIM auto-provisioning and deprovisioning users from a company directory
• SAML service provider and OIDC relying party protocol-specific names for the app trusting an identity provider
• ID token OIDC token carrying authenticated user identity claims
• OAuth redirect URI / callback URL registered destination receiving the authorization response
• Client ID and client secret credentials identifying an OAuth client application
• OAuth state parameter correlates requests and helps prevent OAuth login attacks
• One-time password (OTP) single-use code delivered by email, SMS, or authenticator
• Recovery codes one-time backup codes when the second factor is lost
• Account recovery regaining access after losing authentication factors
• Global sign-out invalidating all active sessions across every device
• Silent refresh renewing auth in the background without user interruption
• Step-up authentication re-prompting for MFA before a sensitive action
• WebAuthn the browser standard underneath passkeys and hardware keys
• Hardware security key physical USB/NFC device proving presence
• Trusted device recognition remembering a known device to skip repeat MFA
• Attribute-based access control (ABAC) permissions from user/resource attributes, not fixed roles
• Relationship-based access control (ReBAC) permissions derived from relationships between users and resources
• Permission / policy engine centralized service answering "can this user do that?"
• Identity federation trusting identities authenticated by another administrative domain
• Just-in-time (JIT) provisioning creating the account automatically on first SSO login
• Anonymous / guest user usable identity before signup, upgradeable later
• Domain verification and domain-based enrollment proving a company email domain, then auto-joining its users
• Invite flow invitations, pending states, and acceptance into a workspace
• Audit log (auth events) recorded trail of logins, role changes, and grants
• Machine-to-machine auth (client credentials) services authenticating without any user present
• Service account non-human identity a system uses to act
• mTLS (mutual TLS) both client and server prove identity with certificates
• Impersonation (login as user) staff safely assumes a user's session for support
• Age assurance and identity proofing establishing a person's age or real-world identity