Glossary

I keep this list of the terms I use in essays about OAuth, OpenID Connect, JSON Web Tokens, passwords and agent identity, with a one-line meaning for each and the RFC or specification that defines it where there is one. When an essay uses an acronym such as OIDC or PKCE for the first time, it links to the entry here.

A

Access token #: A credential the client presents to a resource server to access protected resources. It stands for a specific scope and lifetime, and the client should treat it as opaque, even when it’s a JWT (RFC 6749, section 1.4).
See: JWT vs OAuth 2.0: Understanding the Key Differences
Account pre-hijacking #: An attack class described by Sudhodanan and Paverd in which the attacker acts before the victim creates an account, for example by registering with the victim’s email address, and gains access once the victim signs up or recovers the account.
See: How do attackers take over accounts?
Account takeover #: An attacker gains control of someone else’s account, for example through credential stuffing, phishing, session theft or a weak account recovery flow.
See: How do attackers take over accounts?, How secure are email-based password resets?
ACR Authentication Context Class Reference #: An OpenID Connect claim (acr) that names the assurance level of the user’s authentication. Clients request a level with the acr_values parameter, and the values themselves are agreed between the provider and the client.
See: Step-Up Authentication: Elevating Security with OpenID Connect (OIDC)
AMR Authentication Methods References #: An OpenID Connect claim (amr) that lists the methods the user authenticated with, such as pwd, otp, hwk or mfa. RFC 8176 registers the standard values.
See: Step-Up Authentication: Elevating Security with OpenID Connect (OIDC)
Audience #: The recipient a token is meant for, carried in the JWT aud claim. A resource server must reject a token whose audience doesn’t name it, otherwise a token issued for one API works at another.
See: How does authorization work for MCP servers?
Authorization code flow #: The OAuth flow for apps with a user present (RFC 6749, section 4.1). The browser takes the user to the authorization server, which redirects back with a short-lived code, and the client exchanges that code for tokens over a direct back-channel request. Combine it with PKCE.
See: Where do OpenID Connect implementations break?

B

Bearer token #: An access token that anyone who holds it can use, with no proof that they’re the client it was issued to (RFC 6750). Most OAuth access tokens are bearer tokens, so a leaked token is as good as a stolen key until it expires. DPoP and mTLS-bound tokens close that gap.
Brute-force attack #: Guessing a password by trying many candidates against one account, either online against the login form or offline against a stolen hash. Rate limiting stops the online variant; slow password hashing slows the offline one.
See: Password Attack Guide: What is Password Spraying?

C

Claim #: A name/value pair in a JWT that asserts something about the subject, such as sub for the user ID or exp for the expiry time (RFC 7519). Registered claims have fixed meanings; anything else is a public or private claim.
See: The Purpose of JWT: Stateless Authentication
Client credentials grant #: The OAuth grant a client uses to get an access token for itself, with no user involved (RFC 6749, section 4.4). It’s the usual choice for service-to-service calls, and the token carries the client’s own permissions.
Coding agent #: A language model run in a loop with tools to read, edit and run code in a repository, such as a shell and a file editor. It acts with whatever credentials and permissions its environment gives it.
See: AppSec in the Age of Agentic Engineering, What I Learned Building an Identity Broker With Coding Agents
Consent #: The user’s explicit approval for a specific client to access specific scopes on their behalf, usually on a screen the authorization server shows. A good consent grant names the client, the access and the duration, and the user can withdraw it later.
See: How should people grant and revoke an agent's access?
Credential stuffing #: An attacker takes username and password pairs leaked from one site and tries them automatically on other sites. It works because people reuse passwords.
See: How do you protect accounts from stolen credentials?, How common is password reuse?

D

DAST Dynamic Application Security Testing #: Tools that look for vulnerabilities by sending requests to a running application from the outside, without access to its source.
See: AppSec in the Age of Agentic Engineering
Delegation #: One principal acts on behalf of another while keeping its own identity. RFC 8693 expresses this with the act claim, so a resource server can see both the user and the agent acting for them.
See: Should an agent use a robot account or delegated access?
DPoP Demonstrating Proof of Possession #: A way to bind access and refresh tokens to a key pair the client holds (RFC 9449). The client signs a short JWT proof for every request and sends it in the DPoP header, so a stolen token is useless without the private key.

F

FIDO2 #: The FIDO Alliance’s name for WebAuthn together with CTAP (Client to Authenticator Protocol), which lets a browser talk to a security key or phone. Passkeys are FIDO2 credentials.
See: Passwordless: Critical Notes on FIDO2 Passkeys, Passwordless Authentication: Future of Cybersecurity

H

Honeytoken #: A decoy credential or account that no legitimate user or process ever uses. Any attempt to log in with it means someone has access to data they shouldn’t, so it triggers an alert. Honeytokens detect breaches; they don’t prevent them.
See: Honeytoken: Authentication Attack Breach Detection

I

ID token #: A signed JWT that an OpenID Connect provider issues to the client after the user authenticates. It must carry iss, sub, aud, exp and iat, and can carry acr, amr and auth_time. The client reads it to log the user in; it isn’t meant for calling APIs.
See: Step-Up Authentication: Elevating Security with OpenID Connect (OIDC)
Impersonation #: One principal gets all the rights of another and is indistinguishable from them in the issued token (RFC 8693, section 1.1). Downstream services can’t tell who actually made the request.
See: Should an agent use a robot account or delegated access?
Issuer #: The party that created and signed a token, carried in the JWT iss claim as a URL. A verifier checks that the issuer is one it trusts and fetches that issuer’s signing keys from its JWKS.
See: Mastering JWKS: JSON Web Key Sets Explained

J

JOSE JSON Object Signing and Encryption #: The IETF family of specifications for signing and encrypting JSON: JWS, JWE, JWK and JWA, with JWT built on top. The name comes from the IETF working group that wrote them.
See: What is JWA? A Deep Dive into JSON Web Algorithms, JSON Web Encryption: Exploring JWE Token
JWA JSON Web Algorithms #: The registry of algorithm identifiers that JWS, JWE and JWK use, such as RS256, ES256, RSA-OAEP and A256GCM (RFC 7518). A verifier should accept only the algorithms it expects, never whatever the token header claims.
See: What is JWA? A Deep Dive into JSON Web Algorithms
JWE JSON Web Encryption #: A format for encrypted content (RFC 7516). The compact form has five parts: header, encrypted key, initialization vector, ciphertext and authentication tag.
See: JSON Web Encryption: Exploring JWE Token
JWK JSON Web Key #: A JSON representation of a cryptographic key, with members such as kty, kid and use (RFC 7517).
See: Mastering JWKS: JSON Web Key Sets Explained
JWKS JSON Web Key Set #: A JSON object whose keys member holds a list of JWKs (RFC 7517, section 5). Issuers publish their public signing keys as a JWKS at a URL, and verifiers pick the right key by its kid, which lets the issuer rotate keys without breaking clients.
See: Mastering JWKS: JSON Web Key Sets Explained
JWS JSON Web Signature #: A format for content protected with a digital signature or a MAC (RFC 7515). The compact form is three base64url parts separated by dots: header, payload and signature. Anyone can read the payload, so a JWS doesn’t hide data.
See: The Purpose of JWT: Stateless Authentication
JWT JSON Web Token #: A compact, URL-safe format for claims, packaged as a JWS (signed) or a JWE (encrypted) (RFC 7519). A verifier must check the signature, the algorithm, iss, aud and exp before trusting any claim; RFC 8725 lists the current best practices.
See: The Purpose of JWT: Stateless Authentication, JWT vs OAuth 2.0: Understanding the Key Differences, Single-Use JWT: Unlocking the Power of Stateless One Time Token

L

Least privilege #: Saltzer and Schroeder’s 1975 design principle that every program and user should operate with the least set of privileges necessary to complete the job. For tokens, that means narrow scopes, a single audience and short lifetimes.
See: Shift Down: Why Agentic Engineering Demands Platform-Level Security

M

MCP Model Context Protocol #: An open protocol, introduced by Anthropic in November 2024, that connects AI applications to servers exposing tools, resources and prompts. Authorization is optional; HTTP-based servers that use it act as OAuth resource servers, publish protected resource metadata (RFC 9728) and must reject tokens issued for other audiences.
See: How does authorization work for MCP servers?, What I Learned Building an Identity Broker With Coding Agents
MFA Multi-factor authentication #: Authentication that requires factors from at least 2 different categories: something you know, something you have, something you are. A password plus a one-time code is MFA; 2 passwords are not.
See: Do login challenges and risk scoring stop account takeover?
mTLS certificate-bound token #: An access token tied to the client’s TLS certificate (RFC 8705). The authorization server puts the certificate’s SHA-256 thumbprint in the token’s cnf claim, and the resource server only accepts the token over a mutual TLS connection that presents the same certificate.

N

NIST SP 800-63B #: The US National Institute of Standards and Technology guideline for authentication and authenticator management. Revision 4 (2025) requires at least 15 characters for passwords used as a single factor, says verifiers should allow at least 64, forbids composition rules and periodic changes, and requires a blocklist check.
See: How to Design a Strong & Usable Password Policy, Max Password Length: A Secure Password Guide

O

OAuth 2.0 #: An authorization framework that lets a client application get limited access to an HTTP service, either for a user or for itself, without seeing the user’s password. The authorization server issues tokens and the resource server accepts them. Defined in RFC 6749; the IETF is consolidating it with its security best practices as the OAuth 2.1 draft.
See: JWT vs OAuth 2.0: Understanding the Key Differences, On Making Spring Security OAuth RFC-compliant
OIDC OpenID Connect #: An identity layer on top of OAuth 2.0. The client receives an ID token that tells it who the user is and how they authenticated. Defined in OpenID Connect Core 1.0 by the OpenID Foundation.
See: Where do OpenID Connect implementations break?, Step-Up Authentication: Elevating Security with OpenID Connect (OIDC)

P

Passkey #: A FIDO credential that replaces a password with a key pair: the private key stays with the user, the site stores only the public key. The FIDO Alliance distinguishes synced passkeys, which a cloud service copies across the user’s devices, from device-bound passkeys, which never leave one device or security key.
See: Passwordless: Critical Notes on FIDO2 Passkeys, Passwordless Authentication: Future of Cybersecurity
Password hashing #: Storing a password as the output of a deliberately slow, salted function, so a stolen database is expensive to crack. Argon2id (RFC 9106), which won the 2015 Password Hashing Competition, is the usual first choice; bcrypt and scrypt are older options. Fast hashes such as SHA-256 are not suitable.
See: Long Password Support for Safer Login Systems
Password manager #: Software that generates, stores and fills a unique password for each site. Because it fills by domain, it also refuses to fill on a look-alike phishing domain. Login forms with standard autocomplete attributes make it work reliably.
See: How to: Password-Manager Friendly Login Forms
Password reuse #: Using the same password, or a small variation of it, on more than one site. A breach at one site then exposes the user’s accounts everywhere else.
See: How common is password reuse?
Password spraying #: An attacker tries a few common passwords against many accounts, slowly enough that no single account hits its lockout threshold.
See: Password Attack Guide: What is Password Spraying?
Password strength meter #: A widget that rates a password as the user types it. Meters that estimate guessability, for example with a dictionary-based estimator, help users; meters that only count character classes reward predictable passwords like Password1!.
See: Do password strength meters work?, How to Design a Strong & Usable Password Policy
Phishing #: Tricking someone into handing over credentials, approving a login or running something, usually with a message or site that imitates one they trust. Passkeys and password managers resist it because they check the domain; people can’t do that reliably.
See: Whaling Phishing: Definition and Prevention Strategies, Passwordless: Critical Notes on FIDO2 Passkeys
PKCE Proof Key for Code Exchange #: An extension to the authorization code flow (RFC 7636). The client sends a hash of a random code_verifier with the authorization request and the verifier itself with the token request, so an attacker who intercepts the code can’t redeem it. OAuth 2.1 requires it.
See: Where do OpenID Connect implementations break?
Prompt injection #: An attack in which text the model reads, such as a web page, an issue comment or a tool result, contains instructions the model then follows as if they came from the user. The model can’t reliably tell data from instructions, so limiting what the agent can reach is the main defence.
See: AppSec in the Age of Agentic Engineering
Protected resource metadata #: A JSON document a resource server publishes at /.well-known/oauth-protected-resource to say which authorization servers it accepts tokens from (RFC 9728). A 401 response can point to it with a resource_metadata parameter in the WWW-Authenticate header. MCP servers must publish it.
See: How does authorization work for MCP servers?

R

Refresh token #: A long-lived credential the client sends only to the authorization server to get new access tokens when the current ones expire (RFC 6749, section 1.5). The resource server never sees it. OAuth 2.1 requires public clients to use sender-constrained or rotating refresh tokens.
See: The Purpose of JWT: Stateless Authentication
Resource indicators #: The resource parameter a client adds to authorization and token requests to name the API it wants the token for (RFC 8707). The authorization server can then restrict the token’s audience to that one resource. MCP clients must send it.
See: How does authorization work for MCP servers?
Robot account #: A non-human account, also called a service account, with its own long-lived credential. When an agent uses one for many people, it acts with the combined permissions of all of them and the audit log can’t tell whose request was whose.
See: Should an agent use a robot account or delegated access?, What I Learned Building an Identity Broker With Coding Agents

S

Salt #: A random value generated per password and stored next to its hash. It makes identical passwords hash differently and stops attackers from using precomputed tables. A salt isn’t secret.
See: Long Password Support for Safer Login Systems
SAML Security Assertion Markup Language #: An XML-based OASIS standard for exchanging signed authentication and attribute assertions between an identity provider and a service provider. Enterprises still use SAML 2.0 widely for single sign-on, and its XML signature handling has caused repeated vulnerabilities.
See: Weak Crypto, Github SAML Attack & Twitter Security UX
SAST Static Application Security Testing #: Tools that look for vulnerabilities in source code or binaries without running them.
See: AppSec in the Age of Agentic Engineering
SBOM Software Bill of Materials #: A machine-readable inventory of the components and dependencies that make up a piece of software. SPDX and CycloneDX are the common formats.
See: Dependency Updates: latest Is Not a Security Strategy
Scope #: A space-separated list of strings in an OAuth request that says what access the client asks for, such as repo:read (RFC 6749, section 3.3). The authorization server can grant fewer scopes than requested and must tell the client when it does.
Shift down #: Moving security decisions into the platform, so teams get secure defaults such as a standard pipeline or workload credentials instead of building and securing them themselves. Shift-left, by comparison, moves checks earlier in each team’s workflow.
See: Shift Down: Why Agentic Engineering Demands Platform-Level Security
Step-up authentication #: Asking a logged-in user to authenticate again, or with a stronger method, before a sensitive action. In OAuth, a resource server signals this with the insufficient_user_authentication error and the required acr_values or max_age (RFC 9470).
See: Step-Up Authentication: Elevating Security with OpenID Connect (OIDC)

T

Threat modeling #: Analysing a model of a system to find security and privacy concerns. The Threat Modeling Manifesto frames it as 4 questions: what are we working on, what can go wrong, what are we going to do about it, and did we do a good enough job.
See: AppSec in the Age of Agentic Engineering
Token exchange #: A grant in which a client hands the authorization server one token (subject_token, optionally with an actor_token) and gets back a different token, for example one with a narrower audience or one for another service (RFC 8693). The issued token can record delegation in an act claim.
See: How does OAuth 2.0 Token Exchange keep provider tokens away from agents?, What I Learned Building an Identity Broker With Coding Agents
Token revocation #: A client tells the authorization server that a refresh or access token is no longer needed, through the revocation endpoint (RFC 7009). Revoking a refresh token should also invalidate the access tokens from the same grant, but a self-contained JWT access token stays valid at resource servers until it expires unless they check its status.
See: How should people grant and revoke an agent's access?
Trust boundary #: A line in a system where data or control passes between parts with different levels of trust, such as from the internet to an API or from a tool result into an agent’s context. Every input that crosses it needs validation.

W

WebAuthn Web Authentication #: The W3C browser API that lets a website create and use public-key credentials. The browser scopes each credential to the site’s domain, which is why a phishing site can’t use it.
See: Passwordless: Critical Notes on FIDO2 Passkeys
Whaling #: Phishing aimed at senior executives, usually to get them to approve payments or share sensitive data.
See: Whaling Phishing: Definition and Prevention Strategies, What is Whaling Cyber Awareness? Prevention Tips & Training