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 tells the client how the user was authenticated: for example, with a password alone or with multi-factor authentication. A client can request a minimum acceptable level in the authentication request and check the returned value against it. ACR values and their significance 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.
Authentication
Authentication confirms a user's claimed identity in OpenID Connect, typically through credentials like passwords or biometrics. OpenID Connect defines several authentication mechanisms to cater to different requirements, elaborated in OpenID Connect Core 1.0.
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, and then exchanges that code for tokens over a direct server-to-server call. Tokens never pass through the browser, which is what makes this flow the recommended default. In the upcoming OAuth 2.1, it becomes the only flow for user-facing authorization: the implicit and password grants are removed, and PKCE is mandatory. The flow is detailed in OpenID Connect Core 1.0 and RFC 6749.
Authorization Codes
The Authorization Code is a temporary, intermediary token used in the Authorization Code Flow. Issued after a user's authentication and consent, it's exchanged for an access token and possibly a refresh token through a secure server-to-server transaction. This process keeps access tokens secure and prevents them from being exposed in environments like web browsers. The code is generally short-lived and designed for single use to reduce interception risks.
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 user, obtains consent, and issues tokens to clients. It is detailed in OAuth 2.0 and OpenID Connect specifications.
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 secure, server-to-server information exchange over HTTPS, critical for OAuth 2.0 and OpenID Connect operations like token exchange. This method ensures that data passes securely between trusted servers, as described in OpenID Connect and OAuth 2.0.
Back-Channel Logout
Back-Channel Logout in OpenID Connect allows secure server-to-server communication to log out users, so the user's sessions end everywhere at once. 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
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 the process by which a client application proves its identity to the authorization server when requesting tokens. OAuth 2.0 and OpenID Connect define several families of mechanisms: a shared secret sent via an HTTP header or request body, a signed JWT assertion using either a shared secret or a private key, and mutual TLS with a client certificate. The full catalog of method identifiers and their exact semantics is specified in RFC 6749 Section 2.3 and OpenID Connect Core 1.0 Section 9.
Client Secret
A Client Secret acts as a password for the client application to authenticate itself to the authorization server. It ensures only registered and verified clients can request tokens and access user information.
Confidential Client
In OAuth 2.0 and OpenID Connect, a Confidential Client securely stores credentials like a client secret. Operating in controlled environments, these clients authenticate when requesting tokens, enhancing security. Details are in RFC 6749.
Consent
Consent in OpenID Connect is the user's explicit approval to share identity information with a client application. The consent protocol is outlined 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.
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.
Discovery
Discovery mechanisms in OpenID Connect enable clients to automatically find information about OpenID Providers, such as endpoints and capabilities. This automated discovery is detailed in the OpenID Connect Discovery 1.0 specification.
Discovery Document
The Discovery Document in OpenID Connect is a JSON document that contains key configuration information about the OpenID Provider, including supported features and available endpoints. Detailed in the OpenID Connect Discovery 1.0 specification, it supports automatic client configuration.
Dynamic Client Registration
Dynamic Client Registration in OAuth 2.0 allows clients to register with authorization servers dynamically. This is elaborated in RFC 7591.
E
Endpoint
In OAuth 2.0 and OpenID Connect, an Endpoint is a specific URL where a web service can be accessed by a client application. These endpoints enable the structured and secure exchange of information, such as authentication, authorization, token issuance, and user information retrieval. They are elaborated in both OAuth 2.0 and OpenID Connect standards.
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
Front-channel communication
Front-channel communication involves the direct transmission of information through the user's browser, commonly used in authentication and authorization protocols for redirecting users and conveying responses. Despite its susceptibility to interception, it's secured with SSL/TLS and careful token handling. Details are in OpenID Connect and OAuth 2.0 documentation.
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.
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
Identity in OpenID Connect represents a set of claims about a user, authenticated by an Identity Provider (IdP). It includes essential information like the user's name and email. See more in OpenID Connect Core 1.0.
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 URL at the authorization server where token status queries are answered. See Token Introspection for the mechanism.
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.
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) provides a structured way to encrypt JSON objects, ensuring confidentiality of data within a JSON structure. Learn more about JWE at 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.
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
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 parameter in OpenID Connect prevents replay attacks by ensuring that an ID Token cannot be used more than once. It's a unique string included in the authentication request and validated in the ID Token response. Its use is discussed 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 returns OpenID Provider Metadata, so clients can configure themselves automatically. More on this can be found 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 Connect Provider
An OpenID Connect Provider (OP) is a service that authenticates users and issues tokens within the OpenID Connect framework. It supports single sign-on (SSO) and identity federation across services. For an in-depth understanding of OpenID Providers, refer to 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.
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 enhances user privacy by assigning a unique identifier to each user-client pair, preventing tracking across applications. PPIDs keep the user pseudonymous across clients. The concept and implementation of PPIDs are thoroughly explained in the OpenID Connect Core 1.0.
Processing
In the context of web authentication and authorization, Processing involves the handling and validation of tokens and claims. This includes verifying token authenticity, extracting and utilizing user information, and enforcing access policies based on validated claims. Detailed processes and best practices for securely processing authentication and authorization data are outlined in OpenID Connect and OAuth 2.0 protocols.
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 enable clients to specify the target resource server during token requests, directing the authorization server to issue access tokens with appropriate scopes. This specification ensures more granular access control, as described in RFC 8707.
Revocation Endpoint
The Revocation Endpoint is the URL at the authorization server where clients submit tokens to be invalidated. See Token Revocation for the mechanism.
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.
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 allows a Relying Party to initiate the logout process, so the user signs out of all sessions at once. It is specified in OpenID Connect RP-Initiated Logout 1.0.
S
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.
Session
A Session in OpenID Connect is a state that maintains the user's authentication with the client and Identity Provider (IdP). It ensures users remain authenticated across multiple interactions, reducing the need for frequent logins. The OpenID Connect Session Management specification provides detailed guidelines, available at OpenID Connect Session 1.0.
Session Management
Session Management in OpenID Connect involves maintaining and monitoring user sessions to keep users signed in until they log out or the session expires. It includes mechanisms for session creation, maintenance, and termination, as outlined in OpenID Connect Session Management 1.0.
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.
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. Further explanation can be found at Wikipedia.
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.
Subject Identifier
The Subject Identifier (the sub claim) is the stable, unique identifier the OpenID Provider assigns to a user. It can be public (the same value for every client) or pairwise, a different value per client, which prevents clients from correlating the same user across applications. The use and significance of subject identifiers 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 refer to the individual in the OpenID Connect ecosystem. A User interacts with applications, while an End-User is specifically the subject of authentication in OpenID Connect. This distinction is detailed in 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.
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 in web security refers to the process of verifying the authenticity and integrity of tokens and claims, ensuring that the data exchanged between parties is genuine and untampered. Validation techniques and their importance in securing authentication and authorization flows are discussed in both OpenID Connect Core 1.0 and OAuth 2.0 protocols.
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.