# Glossary
**[A](#a)** **[B](#b)** **[C](#c)** **[D](#d)** **[E](#e)** **[F](#f)** **[G](#g)** **[H](#h)** **[I](#i)** **[J](#j)** **[K](#k)** **[L](#l)** **[M](#m)** **[N](#n)** **[O](#o)** **[P](#p)** Q **[R](#r)** **[S](#s)** **[T](#t)** **[U](#u)** **[V](#v)** **[W](#w)** **[X](#x)** Y Z
---
## A
---
### Access Token {#access-token}
An **Access Token** is used in OAuth 2.0 and OpenID Connect for granting a client application access to a user's data on a resource server. It is most often used as a bearer token, although sender-constraining mechanisms such as DPoP and mutual TLS can bind it to the client's key. Access Tokens are designed to be short-lived so a stolen token expires quickly, and can be renewed with a refresh token. Detailed specifications and use cases for Access Tokens are provided in the [OAuth 2.0 specification](https://datatracker.ietf.org/doc/html/rfc6749).
### ACR {#acr}
The **Authentication Context Class Reference (ACR)** claim in an ID Token names the authentication context class that the authentication satisfied: a single password, say, versus a multi-factor step-up. A client lists preferred values in the `acr_values` parameter, but that request is voluntary and the authorization server may return a different value, so the client checks the returned claim before relying on it. ACR values are discussed in [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html#IDToken).
### AMR {#amr}
**Authentication Methods References (AMR)** in OpenID Connect indicate the methods used in the authentication process, such as passwords, biometrics, or OTP. Their usage and examples are provided in [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html#IDToken).
### Argon2 {#argon2}
**Argon2** is a password-hashing function that won the Password Hashing Competition and is designed to resist both memory and time-based attacks. More details can be found at [GitHub Repository of PHC Winner Argon2](https://github.com/P-H-C/phc-winner-argon2).
### ASP.NET MVC {#asp-net-mvc}
**ASP.NET MVC** is a web application framework developed by Microsoft, which implements the model-view-controller pattern. More details are available at [Microsoft Docs](https://learn.microsoft.com/en-us/aspnet/core/mvc/overview).
### Attestation {#attestation}
**Attestation** is the signed statement a WebAuthn authenticator returns at registration, vouching for the make and model of the device that created the credential. Verifying it is what makes authenticator policy possible: admitting only approved models, or revoking every credential from a model later found vulnerable. It is defined in [Web Authentication Level 3](https://www.w3.org/TR/webauthn-3/#sctn-attestation).
### Authentication {#authentication}
**Authentication** establishes that the end-user is the party the identifier names, and in OpenID Connect it happens at the provider, never at the client. The protocol deliberately leaves the credential mechanism unspecified: passwords, passkeys, and second factors are all out of scope. What it standardizes is the result, an ID Token whose `acr` and `amr` claims report how the check was performed. See [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html#Authentication).
### Authenticator {#authenticator}
An **Authenticator** in WebAuthn is the component that holds the private key and performs the cryptographic operation: a platform authenticator built into the device, or a roaming one such as a security key or a nearby phone. The private key is never sent to the server, so a [passkey](#passkey) cannot be leaked by a breach, although a credential created as backup-eligible may sync to the owner's other devices. The role is defined in [Web Authentication Level 3](https://www.w3.org/TR/webauthn-3/#authenticator).
### Authorization Code Flow {#authorization-code-flow}
The **Authorization Code Flow** is the primary flow in OAuth 2.0 and OpenID Connect. The user authenticates at the authorization server, the client receives a short-lived authorization code through a browser redirect, then exchanges it for tokens over a direct server-to-server call, so tokens never pass through the browser. In [OAuth 2.1](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1) it becomes the only flow for user-facing authorization, with the implicit and password grants removed and PKCE required of every client but a confidential one whose nonce validation the server trusts. The flow is detailed in [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth) and [RFC 6749](https://datatracker.ietf.org/doc/html/rfc6749).
### Authorization Codes {#authorization-codes}
The **Authorization Code** is a short-lived credential the authorization server hands the client through the browser redirect, standing in for the tokens themselves. The client redeems it at the token endpoint over a direct server-to-server call, which keeps access tokens out of the browser. A code is single use: a second redemption is refused, and any tokens already issued from it are revoked. The rules are in [RFC 6749](https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.2).
### Authorization Endpoint {#authorization-endpoint}
The **Authorization Endpoint** is where the client redirects the user to authenticate and approve or deny access to their data. Successful authentication and consent lead to the issuance of an authorization code or tokens. This endpoint's operation is detailed in both the [OAuth 2.0 specification](https://datatracker.ietf.org/doc/html/rfc6749#section-3.1) and the [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint).
### Authorization Server {#authorization-server}
The **Authorization Server** authenticates the end-user, obtains consent, and issues tokens; in OpenID Connect the same server acts as the [OpenID Provider](#openid-connect-provider) and signs ID Tokens. It owns the authorization, token and key set endpoints, decides what each client may receive, and is the only party a client trusts to assert who the user is. It is detailed in [RFC 6749](https://datatracker.ietf.org/doc/html/rfc6749#section-1.1) and [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html).
### Authorization Server Issuer Identifier {#authorization-server-issuer-identifier}
The **Authorization Server Issuer Identifier** is the URL that uniquely identifies an authorization server. Clients compare it against the `iss` values in tokens and responses to confirm they are talking to the server they think they are. The identifier is defined in [RFC 8414](https://datatracker.ietf.org/doc/html/rfc8414) and returned in authorization responses per [RFC 9207](https://datatracker.ietf.org/doc/html/rfc9207) to prevent mix-up attacks.
### AZP {#azp}
The **Authorized Party (AZP)** claim in an OpenID Connect ID Token carries the client ID of the party the token was issued to. It matters when the token's audience (`aud`) is not exactly that client: the receiver can tell who the token was meant for and who actually requested it. More about the AZP claim can be found in [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html#IDToken).
## B
---
### Back-channel communication {#back-channel-communication}
**Back-channel communication** is a direct HTTPS call between servers that never passes through the browser: token requests, introspection, revocation and back-channel logout all use it. The caller authenticates itself on this channel and no intermediary reads the payload, which is why secrets and tokens are exchanged here rather than through redirects.
### Back-Channel Logout {#back-channel-logout}
**Back-Channel Logout** in OpenID Connect notifies each relying party of a logout through a direct server-to-server request carrying a [logout token](#logout-token), with no browser involved. How much ends depends on that token: a `sid` claim names one session at the relying party, while a token carrying only `sub` asks it to end every session it holds for that user. The mechanism is detailed in [OpenID Connect Back-Channel Logout 1.0](https://openid.net/specs/openid-connect-backchannel-1_0.html).
### Bcrypt {#bcrypt}
**Bcrypt** is a password hashing function designed for secure password storage by incorporating a salt and repeated hashing. Further information can be found at [Wikipedia](https://en.wikipedia.org/wiki/Bcrypt).
### Bearer Token Usage {#bearer-token-usage}
**Bearer Token Usage** in OAuth 2.0 and OpenID Connect involves the client presenting the bearer token to access protected resources. The possession of the token grants the bearer access. Bearer tokens must be protected from unauthorized access and theft, as outlined in [RFC 6750](https://datatracker.ietf.org/doc/html/rfc6750), which discusses the security considerations and best practices for bearer token usage.
### BFF {#bff}
**Backend for Frontend (BFF)** is an architectural pattern for browser-based applications in which a dedicated server-side component performs the OAuth 2.0 / OpenID Connect flows and keeps the tokens, while the browser talks to that component through session cookies. Keeping tokens out of the browser removes the most common XSS token-theft vector. The pattern and its security rationale are described in [OAuth 2.0 for Browser-Based Applications](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps#name-backend-for-frontend-bff).
## C
---
### CAEP {#caep}
The **Continuous Access Evaluation Profile (CAEP)** defines events describing changes to a user's sessions and access context after login: a revoked session, a changed credential, a shifted assurance or risk level. Services consume them over the [Shared Signals Framework](#ssf) and react at once, instead of waiting for the next authentication to notice. The profile is [OpenID Continuous Access Evaluation Profile 1.0](https://openid.net/specs/openid-caep-1_0.html).
### Ceremony {#ceremony}
A **Ceremony** in WebAuthn is one complete interaction spanning the relying party, the browser and the [authenticator](#authenticator): registration creates a credential, authentication proves possession of one. The term exists because the security argument covers the whole sequence including the person at the keyboard, not just the protocol messages. It is defined in [Web Authentication Level 3](https://www.w3.org/TR/webauthn-3/#ceremony).
### Check Session Iframe {#check-session-iframe}
The **`session_state` value** and the **check session iframe** are the OpenID Connect Session Management mechanism for a client to notice that the provider's session ended, without polling an endpoint. The client hosts a hidden iframe from the provider's origin and asks it, through `postMessage`, whether the session still matches the `session_state` it was given, which is also why the provider's session cookie is script-readable. The mechanism is defined in [OpenID Connect Session Management 1.0](https://openid.net/specs/openid-connect-session-1_0.html).
### CIBA {#ciba}
**Client-Initiated Backchannel Authentication (CIBA)** is an OpenID Connect flow in which the client starts authentication through a back-channel request instead of redirecting the user's browser, and the user approves the request on a separate authentication device such as a phone. The flow defines three token delivery modes: poll, ping, and push. The specification is [OpenID Connect Client-Initiated Backchannel Authentication Flow: Core 1.0](https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html).
### Claims {#claims}
**Claims** in OpenID Connect are pieces of information asserted about a user, such as the user's name or email address. These are included in the ID Token and carry user identity information from the provider to the client. The standard set of claims and their usage is defined in [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims).
### Client Application {#client-application}
**Client Application** is the application that wants to authenticate users or call APIs on their behalf: a server-side web app, a single-page app, a mobile app, or a background service. In OAuth 2.0 and OpenID Connect terminology, the client is always this application, not the user's browser or device. Detailed information can be found at [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html#Terminology).
### Client Authentication {#client-authentication}
**Client Authentication** is how a client application proves its identity to the authorization server, chiefly at the token endpoint. The usual methods are a shared secret sent in an HTTP header or the request body, a signed JWT assertion using either that shared secret or a private key, and mutual TLS with a client certificate, defined respectively in [RFC 6749 Section 2.3](https://datatracker.ietf.org/doc/html/rfc6749#section-2.3), [OpenID Connect Core 1.0 Section 9](https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication), and [RFC 8705](https://datatracker.ietf.org/doc/html/rfc8705).
### Client Secret {#client-secret}
A **Client Secret** is the password a confidential client uses to authenticate at the token endpoint, sent either in an `Authorization` header as `client_secret_basic` or in the request body as `client_secret_post`. Because the authorization server has to be able to check it, deployments that prefer not to hold one authenticate with a signed JWT assertion or [mutual TLS](#mutual-tls-client-authentication) instead. Client credentials are defined in [RFC 6749](https://datatracker.ietf.org/doc/html/rfc6749#section-2.3.1).
### Confidential Client {#confidential-client}
A **Confidential Client** runs where its credentials stay beyond the end-user's reach, typically on a server the developer operates, and it therefore authenticates itself at the token endpoint with a secret, a signed JWT assertion, or a client certificate. That authentication is what lets the authorization server refuse a code exchange from anyone impersonating the client. Client types are defined in [RFC 6749](https://datatracker.ietf.org/doc/html/rfc6749#section-2.1).
### Confused Deputy {#confused-deputy}
A **Confused Deputy** is a component holding more authority than its caller that can be talked into using it on the caller's behalf. In OAuth the authorization server is the deputy: a token issued for a resource the client was never meant to reach, or a redirect to an address it never registered, means the deputy acted on someone else's intent. The pattern was named by Norm Hardy in 1988, and its OAuth forms are cataloged in the [OAuth 2.0 Security Best Current Practice](https://datatracker.ietf.org/doc/html/rfc9700).
### Consent {#consent}
**Consent** is the authorization decision the provider obtains before releasing the user's information to a client or granting it access. It is usually collected through an interactive dialogue listing the requested scopes, but it may instead be established beforehand, for example by prior administrative approval, so a returning user is not necessarily prompted again. The requirement is stated in [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html#Consent).
### CORS {#cors}
**Cross-Origin Resource Sharing (CORS)** is a browser mechanism that lets a web page from one origin call resources on another origin: something the same-origin policy forbids by default. The server opts in by returning specific response headers, and the browser enforces the declared rules. Implementing guidelines can be found at [Fetch Living Standard](https://fetch.spec.whatwg.org/#cors-protocol).
### CSP {#csp}
A **Content Security Policy (CSP)** is a response header naming the sources a page may load scripts and other resources from, and what inline code it may execute. It does not remove an [XSS](#xss) vulnerability; it limits what injected code can do and where it can send what it steals, which is why it appears among the defense-in-depth measures for a client that still handles tokens itself. The header is specified in [Content Security Policy Level 3](https://www.w3.org/TR/CSP3/).
### CSRF {#csrf}
**Cross-Site Request Forgery (CSRF)** makes the user's browser send an authenticated request to an application from a page the attacker controls, relying on the browser to attach the session cookie automatically. In OAuth the authorization response is defended by PKCE or the nonce, with state as the older equivalent, while a BFF needs an anti-forgery token to defend its own API. The countermeasures are in [RFC 9700](https://datatracker.ietf.org/doc/html/rfc9700#section-4.7).
## D
---
### Device Authorization Grant {#device-authorization-grant}
The **Device Authorization Grant** is an OAuth 2.0 extension enabling devices with no browser or limited input capability to authenticate and authorize users. The user completes the authorization on a second device, such as a phone. This grant type is particularly useful for IoT devices and smart appliances. Detailed guidance on its implementation can be found in [RFC 8628](https://datatracker.ietf.org/doc/html/rfc8628).
### DI {#di}
**Dependency Injection (DI)** is a design pattern that allows for Inversion of Control between classes and their dependencies. This makes classes easier to test and swap. For more official details, visit [Microsoft Docs](https://learn.microsoft.com/en-us/dotnet/core/extensions/dependency-injection/overview).
### Discoverable Credential {#discoverable-credential}
A **Discoverable Credential**, historically called a resident key, is a WebAuthn credential stored on the [authenticator](#authenticator) together with the user handle it belongs to. Because the authenticator can list its own credentials, the site asks for any credential it accepts and the device offers the matching accounts, which is what makes usernameless [passkey](#passkey) sign-in possible. It is defined in [Web Authentication Level 3](https://www.w3.org/TR/webauthn-3/#discoverable-credential).
### Discovery {#discovery}
**Discovery** in OpenID Connect is how a client configures itself against a provider with no hand-entered settings. It covers two mechanisms: WebFinger resolves a user-supplied identifier such as an email address to an issuer, and a request to that issuer's well-known configuration path returns the provider's metadata. Both are defined in [OpenID Connect Discovery 1.0](https://openid.net/specs/openid-connect-discovery-1_0.html).
### Discovery Document {#discovery-document}
The **Discovery Document** is the informal name for the JSON that an OpenID Provider publishes at its well-known configuration path. See [OpenID Provider Metadata](#openid-provider-metadata) for the field set, and [Discovery Endpoint](#openid-configuration-discovery-endpoint) for the URL it is served from.
### DPoP Nonce {#dpop-nonce}
A **DPoP Nonce** is a server-supplied value the client must include in its next DPoP proof, returned in the `DPoP-Nonce` header when the server demands one. It pins the proof to a moment the server chose, so a proof harvested earlier cannot be replayed later, and it removes any need to trust the client's clock. The mechanism is specified in [RFC 9449](https://datatracker.ietf.org/doc/html/rfc9449#section-8).
### Dynamic Client Registration {#dynamic-client-registration}
**Dynamic Client Registration** lets a client obtain OAuth 2.0 credentials at runtime by posting its own metadata to the registration endpoint: redirect URIs, grant types, and the token endpoint authentication method among them. The server assigns a `client_id`, adds a secret where the client is confidential, and echoes back the metadata it accepted. Because an open registration endpoint lets anyone create clients, access to it is normally gated. It is specified in [RFC 7591](https://datatracker.ietf.org/doc/html/rfc7591).
## E
---
### EdDSA {#eddsa}
The **Edwards-curve Digital Signature Algorithm (EdDSA)** is used in JOSE with the Ed25519 and Ed448 curves and represented by the `OKP` key type. Its signatures are deterministic, small and fast to verify, so it appears in passkey and token-signing configurations as the alternative to ECDSA that removes the nonce-generation failure mode rather than raising the security level. Its use in JOSE is defined in [RFC 8037](https://datatracker.ietf.org/doc/html/rfc8037).
### Endpoint {#endpoint}
In OAuth 2.0 and OpenID Connect, an **Endpoint** is one of a fixed set of protocol-defined URLs: authorization, token, UserInfo, introspection, revocation, registration, end session, and the key set. The roles are standardized but the paths are not, so a provider publishes its own URL for each role in its metadata and clients resolve them at runtime. The metadata fields are listed in [OpenID Connect Discovery 1.0](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata).
### Essential Claim {#essential-claim}
An **Essential Claim** in OpenID Connect specifies a claim that the client application deems necessary for its operation. The use and requirements for essential claims are discussed in the [OpenID Connect Core 1.0 specification](https://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter).
## F
---
### FAPI {#fapi}
The **Financial-grade API (FAPI)** is a high-security profile of OAuth 2.0 and OpenID Connect for scenarios where the stakes justify tighter rules, such as open banking and payments. It adds no endpoints but narrows the existing ones, requiring measures such as PAR and sender-constrained tokens while forbidding weaker options the base specifications still allow. The current profile is the [FAPI 2.0 Security Profile](https://openid.net/specs/fapi-security-profile-2_0-final.html).
### FIDO2 {#fido2}
**FIDO2** is the joint FIDO Alliance and W3C effort behind phishing-resistant sign-in: [WebAuthn](#webauthn), the browser API, plus CTAP, the protocol between the browser and an external [authenticator](#authenticator). A [passkey](#passkey) is a FIDO2 credential, and the two terms are often used loosely for the same thing. The composition is described by the [FIDO Alliance](https://fidoalliance.org/specifications/).
### Front-channel communication {#front-channel-communication}
**Front-channel communication** passes information through the user's browser rather than between servers: the authorization request, the redirect carrying the code or tokens back, and front-channel logout all travel this way. Everything on it is visible to the browser and lands in history and logs, which is why the code is short-lived and single-use and why tokens are no longer returned here.
### Front-Channel Logout {#front-channel-logout}
The **Front-Channel Logout** process in OpenID Connect provides a method for logging out users across multiple applications using the browser's front channel. Details on implementing this logout mechanism are provided in the [OpenID Connect Front-Channel Logout 1.0](https://openid.net/specs/openid-connect-frontchannel-1_0.html).
## G
---
### Grant Type {#grant-type}
A **Grant Type** in OAuth 2.0 identifies the method a client uses to obtain an access token from the authorization server: for example, an authorization code, client credentials, a refresh token, or a device code. Each grant type fits a particular class of applications and trust models. The core grant types are defined in [RFC 6749](https://datatracker.ietf.org/doc/html/rfc6749), with additional grants introduced by later specifications.
## H
---
### Hexagonal Architecture {#hexagonal-architecture}
The **Hexagonal Architecture**, or Ports and Adapters, structures an application to promote separation of concerns. Core logic resides at the center, while interactions with the outside world occur through 'ports' with corresponding 'adapters'. Components can be swapped and tested in isolation.
### HSM {#hsm}
A **Hardware Security Module (HSM)** is a tamper-evident, intrusion-resistant device that generates and stores private keys and performs cryptographic operations inside its own boundary, so key material never appears in application memory. For a token-signing service that is the strongest form of key custody: an attacker with full access to the host can ask the HSM to sign, but cannot walk away with the key. It is defined in the [NIST glossary](https://csrc.nist.gov/glossary/term/hardware_security_module_hsm).
### Hybrid Flow {#hybrid-flow}
The **Hybrid Flow** in OpenID Connect combines elements of the Authorization Code and Implicit Flows, so the client chooses how tokens are returned. It's useful for applications requiring immediate access to an ID Token while also needing an authorization code to obtain an access token. The Hybrid Flow is elaborated in [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html#HybridFlowAuth).
## I
---
### ID / Identifier {#id-identifier}
An **ID**, or **Identifier**, is a value that uniquely names an entity within the protocol: `sub` identifies the user, `client_id` identifies the client application, `iss` identifies the token issuer. Stable identifiers are what let independent systems agree they are talking about the same user or client. For in-depth details, see [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html#IDToken).
### ID Token / Identity Token {#id-token-identity-token}
An **ID Token** in OpenID Connect is a JSON Web Token (JWT) that contains authenticated user identity information. Issued by the Authorization Server, it includes claims like the issuer, subject, and audience, essential for verifying the user's identity. The concept and usage of ID Tokens are detailed within [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html#IDToken).
### Identification {#identification}
**Identification** within the OpenID Connect protocol involves presenting a unique identifier such as a username or email. This initial action is distinct from authentication; it merely signals the system to recognize the user's claimed identity. Detailed guidance on identification can be found in the [OpenID Connect Core 1.0 specification](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest).
### Identity {#identity}
In OpenID Connect an **Identity** is not a record the client stores but a set of claims a provider asserts at a moment in time, trustworthy only while the token carrying them verifies and remains unexpired. Because `sub` is unique only within one issuer, clients key their accounts on the `iss` and `sub` pair together, which keeps two providers from colliding on the same user.
### Identity Provider {#identity-provider}
An **Identity Provider** (IdP) authenticates users and manages digital identities within OpenID Connect and SAML protocols. By enabling SSO, IdPs let one login work across many applications. More on IdPs is in [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html).
### Implicit Flow {#implicit-flow}
The **Implicit Flow** in OpenID Connect was designed for clients incapable of securely maintaining a client secret, such as browser-based applications. It directly returns tokens to the client following authentication, bypassing the need for an authorization code exchange. This flow, specified in [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowAuth), is no longer recommended for security reasons.
### Introspection Endpoint {#introspection-endpoint}
The **Introspection Endpoint** is the authorization server URL where a resource server or client submits a token and receives its current status: whether the token is active, and the scope, subject, client and expiry it carries. The request is authenticated and travels over the back channel, so the endpoint is never reached from a browser. See [Token Introspection](#token-introspection) for the mechanism, defined in [RFC 7662](https://datatracker.ietf.org/doc/html/rfc7662#section-2).
### Issuer {#issuer}
An **Issuer** in OpenID Connect is responsible for user authentication and token issuance, identified by a unique URI. The role of the Issuer is elaborated in the OpenID Connect Core 1.0 specification, accessible at [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html#IssuerIdentifier).
## J
---
### JAR {#jar}
**JWT Secured Authorization Request (JAR)** enhances OAuth 2.0 by allowing clients to send requests as JWTs, securing parameters against tampering. This is documented in [RFC 9101](https://datatracker.ietf.org/doc/html/rfc9101).
### JARM {#jarm}
The **JWT Secured Authorization Response Mode (JARM)** returns the authorization response parameters inside a signed, and optionally encrypted, JWT instead of as plain query or fragment values. That gives the response the integrity and authenticity the request already gets from JAR, so a client can prove the response came from the expected issuer and was not tampered with in the browser. The mode is specified in [JWT Secured Authorization Response Mode for OAuth 2.0](https://openid.net/specs/oauth-v2-jarm-final.html).
### JOSE {#jose}
The **JSON Object Signing and Encryption (JOSE)** suite of standards enables secure transmission of JSON objects through signing and encryption. It comprises JWT, JWS, JWE, and JWK. OpenID Connect and OAuth 2.0 use JOSE to sign and encrypt exchanged data. More on JOSE standards can be explored at [RFC 7515 (JWS)](https://datatracker.ietf.org/doc/html/rfc7515) and related documents.
### JWA {#jwa}
The **JSON Web Algorithms (JWA)** standard defines cryptographic algorithms for use in the context of JSON-based data structures, including JWTs, JWS, and JWE. It ensures interoperability by specifying commonly agreed-upon algorithms for digital signatures, encryption, and key management. Specification details can be found at [RFC 7518](https://datatracker.ietf.org/doc/html/rfc7518).
### JWE {#jwe}
**JSON Web Encryption (JWE)** represents encrypted content using JSON-based data structures. The plaintext is arbitrary content rather than necessarily a JSON object: the standard governs the container, which carries the protected header, the encrypted key, the initialization vector, the ciphertext, and the authentication tag. JWE is what hides a token's contents from everyone but the intended recipient. The format is specified in [RFC 7516](https://datatracker.ietf.org/doc/html/rfc7516).
### JWK {#jwk}
A **JSON Web Key (JWK)** is a JSON format for representing cryptographic keys. This format allows for easy sharing and usage of keys in web environments. JWKs are fundamental in the JOSE specification for managing keys in a standardized way. Detailed information on JWK can be found in [RFC 7517](https://datatracker.ietf.org/doc/html/rfc7517).
### JWKS {#jwks}
A **JSON Web Key Set (JWKS)** is a collection of JSON Web Keys (JWK) used to distribute public keys. Clients use these keys to verify the signature of JWTs. For detailed information, visit [RFC 7517](https://datatracker.ietf.org/doc/html/rfc7517).
### JWS {#jws}
**JSON Web Signature (JWS)** represents digital signatures or Message Authentication Codes (MACs) for JSON objects, ensuring data integrity and secure message transmission. It is a fundamental part of the JOSE framework, used widely in web security protocols to validate the authenticity of information exchanges. JWTs are signed using JWS. For more details, see [RFC 7515](https://datatracker.ietf.org/doc/html/rfc7515).
### JWT {#jwt}
**JSON Web Token (JWT)** is a compact, URL-safe method of representing claims securely between two parties. Used in authentication and information exchange, JWTs contain encoded JSON objects, including claims and signatures. They are integral to OAuth 2.0 and OpenID Connect for secure user authentication. Detailed standards are outlined in [RFC 7519](https://datatracker.ietf.org/doc/html/rfc7519).
### JWT Profile for OAuth 2.0 Access Tokens {#jwt-profile-for-oauth-2-0-access-tokens}
The **JWT Profile for OAuth 2.0 Access Tokens** standardizes their format as JWT, improving interoperability and security by enabling structured claims. Resource servers can then validate tokens the same way everywhere, as discussed in [RFC 9068](https://datatracker.ietf.org/doc/html/rfc9068).
## K
---
### KMS {#kms}
A **Key Management Service (KMS)** stores keys and performs cryptographic operations on request as a managed service, the hosted counterpart of an [HSM](#hsm). For a token-signing deployment it moves key custody out of the application database into a boundary with its own access control and audit trail. The underlying concept, a key management system, is defined in the [NIST glossary](https://csrc.nist.gov/glossary/term/key_management_system).
## L
---
### Logout Token {#logout-token}
A **Logout Token** is used in OpenID Connect's logout processes to securely convey logout signals between the OpenID Provider and the relying party. It is a JSON Web Token that includes specific claims related to the logout event. The use and format of Logout Tokens are specified in [OpenID Connect Back-Channel Logout 1.0](https://openid.net/specs/openid-connect-backchannel-1_0.html).
## M
---
### Mix-Up Attack {#mix-up-attack}
A **Mix-Up Attack** confuses a client that talks to more than one authorization server, so a code or token issued by one is sent to another, or the client redeems a code at the attacker's token endpoint and hands over its credentials. The defense is for the client to check which issuer actually answered, which is why the authorization response carries an `iss` parameter. The attack is described in the [OAuth 2.0 Security Best Current Practice](https://datatracker.ietf.org/doc/html/rfc9700#section-4.4).
### Mutual TLS Client Authentication {#mutual-tls-client-authentication}
**Mutual TLS Client Authentication** in OAuth 2.0 requires both the client and server to authenticate via TLS. This method is outlined in [RFC 8705](https://datatracker.ietf.org/doc/html/rfc8705).
### MVC Controller {#mvc-controller}
An **MVC Controller** handles user input, processes requests, and returns responses. More details can be found at [Microsoft Docs](https://learn.microsoft.com/en-us/aspnet/core/mvc/controllers/actions).
## N
---
### NCache {#ncache}
**NCache** is an in-memory distributed caching solution for .NET and Java applications, designed to boost application performance by reducing database load. More information is available at [NCache Official Site](https://www.alachisoft.com/ncache/).
### Nonce {#nonce}
The **Nonce** is a random value the client sends in the authentication request, which the OpenID Provider copies unchanged into the `nonce` claim of the ID Token. The client compares the returned value against the one stored for that session, which mitigates replay: an ID Token minted for a different session cannot be injected into this one. It does not limit how many times a token may be used. Its use is defined in [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest).
### NuGet Package {#nuget-package}
**NuGet Package** is a single ZIP file with the .nupkg extension that contains compiled code (DLLs), related files, and a descriptive manifest for use within .NET projects. More details are available at [Microsoft Docs](https://learn.microsoft.com/en-us/nuget/what-is-nuget).
## O
---
### OAuth 2.0 {#oauth-2-0}
**OAuth 2.0** is a widely adopted authorization framework that enables applications to secure designated access to user resources without exposing user credentials. It supports a variety of grant types to accommodate different client types and authorization flows. It is detailed in [RFC 6749](https://datatracker.ietf.org/doc/html/rfc6749).
### OAuth 2.0 DPoP {#oauth-2-0-dpop}
**OAuth 2.0 DPoP (Demonstrating Proof-of-Possession)** binds access and refresh tokens to a cryptographic key held by the client; the client proves possession of that key on every request with a signed DPoP proof. A stolen token is useless without the key, which defeats token replay. The mechanism is specified in [RFC 9449](https://datatracker.ietf.org/doc/html/rfc9449).
### OpenID Configuration / Discovery Endpoint {#openid-configuration-discovery-endpoint}
The **Discovery Endpoint** is the URL formed by appending `/.well-known/openid-configuration` to the issuer identifier. A GET request returns the [OpenID Provider Metadata](#openid-provider-metadata) as JSON: the endpoint URLs, the `jwks_uri`, and the supported scopes, response types, and algorithms, which lets a client configure itself instead of carrying hard-coded values. The path and its rules are defined in [OpenID Connect Discovery 1.0](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig).
### OpenID Connect {#openid-connect}
**OpenID Connect** is an authentication layer on top of OAuth 2.0, allowing clients to verify the identity of end-users and obtain their profile information. It introduces ID Tokens, which carry authenticated user information. The standard is [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html).
### OpenID Provider {#openid-connect-provider}
An **OpenID Provider (OP)** is an authorization server that also authenticates end-users and reports the result to relying parties as an ID Token and UserInfo claims. One provider serves many applications, which is what makes single sign-on and identity federation possible. The role is defined in [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html#Terminology).
### OpenID Provider Metadata {#openid-provider-metadata}
**OpenID Provider Metadata** describes the capabilities of an OpenID Provider, including endpoints and supported features. This information allows clients to dynamically configure themselves to interact with the provider. The metadata format is detailed in the [OpenID Connect Discovery 1.0 specification](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata).
## P
---
### PAR {#par}
**Pushed Authorization Requests (PAR)** improve security by allowing clients to send authorization requests directly to the authorization server, rather than through the user's browser. For more information, refer to [RFC 9126](https://datatracker.ietf.org/doc/html/rfc9126).
### Passkey {#passkey}
A **Passkey** is a [WebAuthn](#webauthn) credential used in place of a password: a key pair whose private half stays in the [authenticator](#authenticator), bound to one site's origin so it does not respond on a lookalike domain. Passkeys cannot be leaked by a server breach, since the server holds only public keys, and a synced passkey is one a platform or password manager replicates across a user's devices. The concept is described by the [FIDO Alliance](https://fidoalliance.org/passkeys/).
### PBKDF2 {#pbkdf2}
**Password-Based Key Derivation Function 2 (PBKDF2)** is a cryptographic algorithm that derives a secure encryption key from a password using a salt and many iterations. More information is available at [RFC 2898](https://datatracker.ietf.org/doc/html/rfc2898#section-5.2).
### PKCE {#pkce}
**Proof Key for Code Exchange (PKCE)** protects the Authorization Code Flow against code interception. The client invents a one-time secret (the code verifier), sends its hash (the code challenge) with the authorization request, and must present the original verifier when exchanging the code for tokens, so a stolen code is useless on its own. Originally designed for public clients, PKCE is now recommended for all clients. Detailed information is available at [RFC 7636](https://datatracker.ietf.org/doc/html/rfc7636).
### PPID {#ppid}
The **Pairwise Pseudonymous Identifier (PPID)** in OpenID Connect gives a user a different `sub` value at each sector rather than one value everywhere, so clients cannot correlate the same person across applications. The sector defaults to the host of the client's registered redirect URI, and a `sector_identifier_uri` widens it, letting a group of clients under one administration share a single value. The algorithm is specified in [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg).
### Processing {#processing}
**Processing** is what a client or resource server does with a token once it arrives: parsing it, verifying the signature against the issuer's published keys, checking the `iss`, `aud`, `exp` and `nonce` values, and only then applying the claims and granted scopes to an access decision. A token failing any single check is rejected outright rather than partially trusted. The checks required for ID Tokens are listed in [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation).
### Public Client {#public-client}
A **Public Client** in OAuth 2.0 and OpenID Connect refers to an application that cannot securely store client secrets, typically due to operating in an environment accessible to the user, such as browsers or mobile devices. Public clients rely on alternative flows like PKCE to maintain security. The distinction between public and confidential clients and the specific requirements for public clients are thoroughly described in [RFC 6749](https://datatracker.ietf.org/doc/html/rfc6749#section-2.1).
## R
---
### Redirection Attacks {#redirection-attacks}
**Redirection Attacks** exploit unvalidated redirects in web applications, leading users to malicious sites. Further details on prevention and examples are available at [CWE-601](https://cwe.mitre.org/data/definitions/601.html).
### Redis {#redis}
**Redis** is an in-memory data structure store, used as a database, cache, and message broker. Further details can be found at [Redis Official Site](https://redis.io/docs/latest/).
### Refresh Token {#refresh-token}
A **Refresh Token** is a component of OAuth 2.0 and OpenID Connect that allows a client to obtain a new access token when the current one expires. It enables long-lived sessions without repeated login prompts. The mechanism is covered in [OAuth 2.0 specification](https://datatracker.ietf.org/doc/html/rfc6749#section-1.5).
### Resource Indicators for OAuth 2.0 {#resource-indicators-for-oauth-2-0}
**Resource Indicators for OAuth 2.0** add a `resource` parameter naming the protected resource the client intends to call. The authorization server uses it to audience-restrict the issued access token to that resource, so a token leaked to one API cannot be replayed against another. It does not change which scopes are granted: the `scope` parameter still expresses that. The parameter is defined in [RFC 8707](https://datatracker.ietf.org/doc/html/rfc8707).
### Revocation Endpoint {#revocation-endpoint}
The **Revocation Endpoint** is the authorization server URL where a client submits an access or refresh token to have it invalidated, typically at logout or when a token may be compromised. The client authenticates the request and names the token in the `token` parameter; revoking a refresh token normally invalidates the access tokens issued from the same grant. See [Token Revocation](#token-revocation) for the mechanism, defined in [RFC 7009](https://datatracker.ietf.org/doc/html/rfc7009#section-2).
### Rich Authorization Requests {#rich-authorization-requests}
**Rich Authorization Requests (RAR)** extend OAuth 2.0 with the `authorization_details` parameter, letting a client express fine-grained permissions as structured JSON objects instead of flat scope strings: for example, a payment of a specific amount to a specific account. The mechanism is specified in [RFC 9396](https://datatracker.ietf.org/doc/html/rfc9396).
### RISC {#risc}
The **Risk Incident Sharing and Coordination (RISC) Profile** defines events for account-level security incidents: a credential compromised, an account disabled or deleted, an identifier changed, a recovery attempt made. Carried over the [Shared Signals Framework](#ssf), they let an incident detected at one provider protect the same user at every federated service. The profile is [OpenID RISC Profile 1.0](https://openid.net/specs/openid-risc-1_0.html).
### RP {#rp}
In OAuth 2.0 and OpenID Connect, a **Relying Party (RP)** / Client is an application that requests and relies on authentication and authorization information provided by an Identity Provider or Authorization Server. It uses tokens to access user data and perform actions on behalf of the user. The roles, registration, and security considerations for relying parties are detailed in [OAuth 2.0](https://datatracker.ietf.org/doc/html/rfc6749) and [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html).
### RP-Initiated Logout {#rp-initiated-logout}
**RP-Initiated Logout** lets a Relying Party redirect the user to the provider's end-session endpoint to ask that the session there be ended. It is a request rather than a command: the provider normally asks the user to confirm, and only once the user agrees does it notify the other relying parties through front-channel or back-channel logout. It is specified in [OpenID Connect RP-Initiated Logout 1.0](https://openid.net/specs/openid-connect-rpinitiated-1_0.html).
## S
---
### SAML {#saml}
**Security Assertion Markup Language (SAML) 2.0** is the earlier federation standard, built on XML assertions posted through the browser rather than on JSON tokens and REST endpoints. It predates OpenID Connect and remains widespread in enterprise single sign-on, so a provider often has to speak both; its identity provider plays the part of an OpenID Provider and its service provider that of a relying party. It is specified by [OASIS](https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf).
### Scope {#scope}
In OAuth 2.0 and OpenID Connect, **Scope** defines the extent of access that the client is requesting over the user's data. It's a parameter in authorization requests that specifies the desired permissions. The concept and application of scopes are detailed in [RFC 6749](https://datatracker.ietf.org/doc/html/rfc6749).
### Security BCP {#security-bcp}
The **OAuth 2.0 Security Best Current Practice (Security BCP)** states what current OAuth security requires, as opposed to what the 2012 core specification permits. It deprecates the Implicit and password grants, requires PKCE for every public client and exact redirect URI matching for every authorization server, and catalogs the attacks the extensions exist to prevent. It is published as BCP 240 and as [RFC 9700](https://datatracker.ietf.org/doc/html/rfc9700).
### Session {#session}
A **Session** is the authenticated state the provider keeps for an end-user, normally a cookie on the provider's own domain, and it is distinct from the session each client keeps after receiving tokens. The provider session is what lets a later authorization request complete without a new login prompt, and it is what `prompt=none`, `max_age` and logout requests act on. See [OpenID Connect Session Management 1.0](https://openid.net/specs/openid-connect-session-1_0.html).
### Session Management {#session-management}
**Session Management** is the OpenID Connect specification that lets a relying party detect that the user's session at the provider has ended. The provider returns a `session_state` value with the authentication response and publishes a `check_session_iframe` URL that a hidden iframe polls through `postMessage`. Because the iframe reads the provider's cookie from a third-party context, browser restrictions on third-party cookies increasingly break it. The mechanism is defined in [OpenID Connect Session Management 1.0](https://openid.net/specs/openid-connect-session-1_0.html).
### SET {#set}
A **Security Event Token (SET)** is a JWT stating that something happened to a subject, such as a revoked session or a changed credential, rather than asserting the subject's identity. That difference matters in validation: a SET is not a credential and is never accepted as one, however much it resembles any other signed JWT. It is the payload format underneath [CAEP](#caep) and [RISC](#risc), specified in [RFC 8417](https://datatracker.ietf.org/doc/html/rfc8417).
### SHA-512 {#sha-512}
**SHA-512** is a cryptographic hash function that generates a 512-bit hash value, commonly used for security applications such as digital signatures and certificates. Further details can be found at [NIST FIPS 180-4](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf).
### Single Responsibility Principle {#srp}
The **Single Responsibility Principle (SRP)** is a foundational concept in object-oriented programming, asserting that a class should have only one reason to change. This principle, part of the SOLID guidelines, emphasizes that a class should tackle one job, reducing complexity and improving maintainability. Note that in authentication literature the same acronym usually denotes the Secure Remote Password protocol, which is unrelated. Further explanation can be found at [Wikipedia](https://en.wikipedia.org/wiki/Single-responsibility_principle).
### Software Statement {#software-statement}
A **Software Statement** is a signed JWT, issued by a party the authorization server trusts, asserting metadata about a piece of client software: its name, its redirect URIs, who published it. Presented during Dynamic Client Registration, it lets the server accept values it would otherwise take on faith from an unauthenticated caller. It is defined in [RFC 7591](https://datatracker.ietf.org/doc/html/rfc7591#section-2.3).
### Spectre {#spectre}
**Spectre** is a class of processor vulnerabilities that abuses speculative execution to read memory across boundaries the system is supposed to enforce. It matters to authentication because an access token sitting in a browser tab's memory then rests on process isolation rather than on any guarantee of the language, which is part of the argument for keeping tokens out of the browser. The vulnerability class is documented at [spectreattack.com](https://spectreattack.com/).
### SSF {#ssf}
The **Shared Signals Framework (SSF)** defines the plumbing by which one party continuously streams security events to another: how a stream is configured and its status checked, which subjects it covers, and whether events are pushed to the receiver or polled by it. It carries the events defined by [CAEP](#caep) and [RISC](#risc), turning federated login from a one-time handshake into an ongoing relationship. The specification is [OpenID Shared Signals Framework 1.0](https://openid.net/specs/openid-sharedsignals-framework-1_0.html).
### SSO {#sso}
**Single Sign-On (SSO)** is an authentication process that allows a user to access multiple applications with one set of login credentials. For more information, see [Wikipedia](https://en.wikipedia.org/wiki/Single_sign-on).
### SSRF {#ssrf}
**Server-Side Request Forgery (SSRF)** tricks a server into making an HTTP request to an address the attacker chose, using the server's network position rather than the attacker's own. An OpenID Provider is exposed by design, because it fetches client-supplied URLs such as a JWKS or a back-channel logout endpoint, so a client registering a link-local metadata address turns a callback into a way to read cloud instance credentials. The attack is described by [OWASP](https://owasp.org/www-community/attacks/Server_Side_Request_Forgery).
### Subject Identifier {#subject-identifier}
The **Subject Identifier** (the `sub` claim) is the stable, unique identifier the OpenID Provider assigns to a user. It is either public, the same value for every client, or pairwise, a distinct value per sector, so clients in different sectors cannot correlate the same user across applications. Subject Identifier types are detailed in [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes).
## T
---
### Token Endpoint {#token-endpoint}
The **Token Endpoint** in OAuth 2.0 and OpenID Connect is where the client exchanges an authorization grant for an access token, refresh token, and sometimes an ID token. The endpoint is detailed in [RFC 6749](https://datatracker.ietf.org/doc/html/rfc6749#section-3.2) and the [OpenID Connect Core 1.0 specification](https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint).
### Token Exchange {#token-exchange}
The **Token Exchange** mechanism in OAuth 2.0 enables the secure exchange of one type of token for another. This feature supports delegation and impersonation use cases, as specified in [RFC 8693](https://datatracker.ietf.org/doc/html/rfc8693).
### Token Introspection {#token-introspection}
**Token Introspection** lets a resource server or client ask the authorization server whether a token is currently active and what scope and metadata it carries. The query is an authenticated back-channel request to the introspection endpoint, giving real-time validation for opaque or revocable tokens. The mechanism is specified in [RFC 7662](https://datatracker.ietf.org/doc/html/rfc7662).
### Token Revocation {#token-revocation}
**Token Revocation** lets a client tell the authorization server that a token (access or refresh) is no longer needed or may be compromised. The server invalidates it, so the token cannot be used again even before its natural expiry. The request goes to the revocation endpoint, and the procedure is specified in [RFC 7009](https://datatracker.ietf.org/doc/html/rfc7009).
## U
---
### User / End-User {#user-end-user}
The terms **User** and **End-User** both name the human participant in an OpenID Connect flow. The specification defines only End-User, so User is an informal synonym rather than a separate role. The end-user is the subject of authentication and of the ID Token, identified by the `sub` claim, and is distinct from the [user agent](#user-agent) that carries the requests. See [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html#Terminology).
### User Agent {#user-agent}
The **User Agent** acts on behalf of the user, typically a web browser, in OpenID Connect flows. The user authenticates and gives consent through it. It is described in [OpenID Connect documentation](https://openid.net/specs/openid-connect-core-1_0.html).
### User Verification {#user-verification}
**User Verification** is the authenticator's check that the right person is present, through a PIN, a fingerprint or a face, as opposed to merely proving the device is. It is what turns a [passkey](#passkey) into two factors in one gesture, and a relying party states whether it is required, preferred or discouraged. It is defined in [Web Authentication Level 3](https://www.w3.org/TR/webauthn-3/#user-verification).
### UserInfo Endpoint {#userinfo-endpoint}
The **UserInfo Endpoint** in OpenID Connect returns claims about the authenticated user in exchange for a valid access token. The set of returned claims depends on the scopes granted during authorization. Its behavior is defined in [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo).
## V
---
### Validation {#validation}
**Validation** is the set of checks performed before a token is trusted: verifying the signature with the issuer's published key, matching `iss` exactly against the expected issuer, confirming the recipient's own identifier appears in `aud`, checking `exp`, and comparing `nonce` with the value sent in the authentication request. Skipping any one of them lets a forged or replayed token pass as genuine. The steps are enumerated in [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation).
### Voluntary Claim {#voluntary-claim}
**Voluntary Claims** in OpenID Connect are optional information pieces that an application may request from a user. These claims can enrich user profiles or enhance application functionality without being critical for operation. The protocol for requesting and using voluntary claims, along with examples, is detailed in the [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter).
## W
---
### WebAuthn {#webauthn}
**Web Authentication (WebAuthn)** is the browser API for public-key credentials: a site asks the browser to create or use a credential, the browser talks to an [authenticator](#authenticator), and the site verifies the returned signature against a stored public key. The browser includes the calling origin in what gets signed, which is what makes the credential useless on a lookalike domain. The API is specified in [Web Authentication Level 3](https://www.w3.org/TR/webauthn-3/).
### Well-Known URI {#well-known-uri}
A **Well-Known URI** is a path under `/.well-known/` reserved for machine-readable metadata, so a client finds a service's configuration from its base address alone. OpenID Connect Discovery uses `/.well-known/openid-configuration` and OAuth Authorization Server Metadata `/.well-known/oauth-authorization-server`; the two describe the same server, but a client knowing only one suffix will not find a provider serving the other. The registry is defined in [RFC 8615](https://datatracker.ietf.org/doc/html/rfc8615).
## X
---
### XSS {#xss}
**Cross-Site Scripting (XSS)** is the injection of attacker-controlled JavaScript into a page, whether through unsanitized input or a compromised dependency. In authentication it is the decisive threat, because injected script runs with exactly the privileges of the application's own code: it reads any token in `localStorage` or memory, calls APIs with the user's session, and can run its own authorization flow. The attack is described by [OWASP](https://owasp.org/www-community/attacks/xss/).