--- author: Jan Brennenstuhl canonical_url: https://www.janbrennenstuhl.eu/glossary/ description: Short definitions of the identity, token, password and agent terms used across the site. id: jb-glossary kind: glossary license: name: CC BY 4.0 scope: Original text; credited third-party media retain their own rights. url: https://creativecommons.org/licenses/by/4.0/ markdown_url: https://www.janbrennenstuhl.eu/glossary/index.md modified: '2026-10-13T00:00:00+02:00' published: '2026-10-13T00:00:00+02:00' review_basis: '' review_status: not-reviewed reviewed: '' series: '' status: published title: Glossary topics: [] --- # Glossary Short definitions of the identity, token, password and agent terms used across the site. 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. **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). **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. **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. **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. **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. **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. **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. **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. **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. **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. **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. **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. **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. **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. **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. **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. **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. **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. **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. **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. **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. **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. **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. **JWK** (JSON Web Key): A JSON representation of a cryptographic key, with members such as `kty`, `kid` and `use` (RFC 7517). **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. **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. **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. **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. **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. **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. **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. **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. **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. **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. **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. **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. **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. **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. **Password spraying**: An attacker tries a few common passwords against many accounts, slowly enough that no single account hits its lockout threshold. **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!`. **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. **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. **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. **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. **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. **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. **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. **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. **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. **SAST** (Static Application Security Testing): Tools that look for vulnerabilities in source code or binaries without running them. **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. **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. **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). **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. **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. **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. **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. **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. **Whaling**: Phishing aimed at senior executives, usually to get them to approve payments or share sensitive data. --- Cite as: Jan Brennenstuhl. "Glossary." Brennenstuhl on Security, 13 October 2026. https://www.janbrennenstuhl.eu/glossary/ License: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) for the original text; credited third-party media keep their own rights.