Cette page n'a pas encore été traduite.

Glossary

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

A

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.

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.

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.

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.

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.

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.

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.

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 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.

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 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 and RFC 6749.

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.

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 and the OpenID Connect Core 1.0.

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 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 and OpenID Connect Core 1.0.

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 and returned in authorization responses per RFC 9207 to prevent mix-up attacks.

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.

B

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 in OpenID Connect notifies each relying party of a logout through a direct server-to-server request carrying a 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.

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.

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, which discusses the security considerations and best practices for bearer token usage.

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.

C

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 and react at once, instead of waiting for the next authentication to notice. The profile is OpenID Continuous Access Evaluation Profile 1.0.

Ceremony

A Ceremony in WebAuthn is one complete interaction spanning the relying party, the browser and the 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.

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.

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.

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.

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.

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, OpenID Connect Core 1.0 Section 9, and RFC 8705.

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 instead. Client credentials are defined in RFC 6749.

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.

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.

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.

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.

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 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.

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.

D

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.

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.

Discoverable Credential

A Discoverable Credential, historically called a resident key, is a WebAuthn credential stored on the 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 sign-in possible. It is defined in Web Authentication Level 3.

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.

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 for the field set, and Discovery Endpoint for the URL it is served from.

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.

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.

E

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.

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.

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.

F

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.

FIDO2

FIDO2 is the joint FIDO Alliance and W3C effort behind phishing-resistant sign-in: WebAuthn, the browser API, plus CTAP, the protocol between the browser and an external authenticator. A 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.

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

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.

G

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, with additional grants introduced by later specifications.

H

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

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.

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.

I

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.

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.

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.

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

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.

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, is no longer recommended for security reasons.

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 for the mechanism, defined in RFC 7662.

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.

J

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.

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.

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) and related documents.

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.

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.

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.

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.

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.

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.

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.

K

KMS

A Key Management Service (KMS) stores keys and performs cryptographic operations on request as a managed service, the hosted counterpart of an 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.

L

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.

M

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.

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.

MVC Controller

An MVC Controller handles user input, processes requests, and returns responses. More details can be found at Microsoft Docs.

N

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.

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.

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.

O

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.

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.

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 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.

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.

OpenID 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.

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.

P

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.

Passkey

A Passkey is a WebAuthn credential used in place of a password: a key pair whose private half stays in the 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.

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.

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.

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.

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.

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.

R

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.

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.

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.

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.

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 for the mechanism, defined in RFC 7009.

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.

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, they let an incident detected at one provider protect the same user at every federated service. The profile is OpenID RISC Profile 1.0.

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 and OpenID Connect Core 1.0.

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.

S

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.

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.

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.

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.

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.

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 and RISC, specified in RFC 8417.

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.

Single Responsibility Principle

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.

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.

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.

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 and RISC, turning federated login from a one-time handshake into an ongoing relationship. The specification is OpenID Shared Signals Framework 1.0.

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.

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.

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.

T

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 and the OpenID Connect Core 1.0 specification.

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.

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.

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.

U

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 that carries the requests. See OpenID Connect Core 1.0.

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.

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 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.

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.

V

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.

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.

W

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, 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.

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.

X

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.