Skip to content
Introducing the next era of Duende IdentityServer. Read our CEO’s announcement

Glossary

The glossary below provides definitions and explanations of commonly used terms and features within the security and identity management domain. Explore each term to gain a deeper understanding of its functionality and relevance.

A client is a piece of software that requests tokens from your IdentityServer - either for authenticating a user ( requesting an identity token) or for accessing a resource (requesting an access token). A client must be first registered with your IdentityServer before it can request tokens and is identified by a unique client ID.

There are many different client types, e.g. web applications, native mobile or desktop applications, SPAs, server processes, etc.

A connected application is any application or service registered with your Duende IdentityServer instance that relies on it for identity, access, or federation. Each connected application has a unique registration that defines how it interacts with IdentityServer and what it is allowed to do.

Connected applications fall into four categories:

  1. Interactive applications use OpenID Connect (OIDC) to authenticate users and obtain tokens. These include web applications, native mobile or desktop applications, and SPAs, each identified by its own Client ID.
  2. Machine-to-machine clients request access tokens without user interaction, typically using the client credentials grant. Background services, APIs calling other APIs, and MCP clients are common examples.
  3. Third-party API consumer that requires a client ID and client secret, typically in a SaaS situation or B2B situation.
  4. SAML Service Providers use SAML 2.0 to establish federated trust with IdentityServer acting as the Identity Provider (IdP), enabling single sign-on for applications that rely on SAML-based authentication.

License: Lite, Standard, Advanced, Custom

Core protocols cover the OpenID Connect (OIDC) and OAuth 2.0 foundations that most applications need. If you’re building a typical web app, API, or mobile client, core protocols handle authentication, token issuance, and token validation out of the box.

Here’s what’s included:

ProtocolWhat It Does
OAuth 2.0 CoreToken-based authorization for APIs
OpenID Connect CoreUser authentication on top of OAuth 2.0
OIDC Discovery / Authorization Server MetadataClients auto-discover your server’s endpoints and capabilities
Authorization Code FlowThe recommended flow for interactive apps (with PKCE)
Client Credentials FlowMachine-to-machine token acquisition
Token ExchangeSwap one token for another across trust boundaries
Step-up AuthenticationRequire stronger authentication for sensitive operations
JSON Web Tokens (JWT)Standard token format for access and identity tokens
JWT Access Token ProfileStructured JWT access tokens per the IETF profile
JWT Client AuthenticationClients authenticate using signed JWTs instead of shared secrets
JWT Introspection ResponseToken metadata returned as a signed JWT
Bearer Token UsageStandard Authorization: Bearer header for API calls
Token RevocationInvalidate tokens before they expire
Token IntrospectionAPIs verify opaque tokens against the server
RP-Initiated / Front-Channel / Back-Channel LogoutFull suite of logout flows
PAR (Pushed Authorization Requests)Clients send auth parameters directly to the server before redirect
DPoP (Demonstrating of Proof-of-Possession)Binds tokens to a client’s key pair so stolen tokens can’t be replayed
Form Post Response ModeAuth responses delivered via POST instead of the query string
Multiple Response TypesSupport for different OAuth response modes

For the majority of .NET applications, core protocols handle every scenario: users log in, APIs validate tokens, machines talk to machines, and sessions end cleanly.

License: Standard, Advanced, Custom

Extended protocols address requirements that go beyond typical web and API scenarios.

ProtocolWhat It Does
mTLS (Mutual TLS)Binds tokens to a client certificate for sender-constrained access
JAR (JWT-Secured Authorization Requests)Wraps the authorization request in a signed JWT for integrity and confidentiality
Resource IndicatorsLets a client specify which API it’s targeting when requesting tokens
CIBA (Client-Initiated Backchannel Authentication)Authentication triggered by a backend service, not a browser redirect
Device Authorization GrantLogin flow for devices without a browser (smart TVs, CLI tools, IoT)
DCR (Dynamic Client Registration)Clients register themselves programmatically instead of being pre-configured

These protocols solve real problems, but they’re problems that surface in specific business contexts rather than in every project.

License: Business (legacy), Enterprise (legacy), Standard (add-on), Advanced, Custom

The automatic key management feature creates and manages key material for signing tokens and follows best practices for handling this key material, including storage and rotation.

License: Business (legacy), Enterprise (legacy), Standard, Advanced, Custom

The server-side session management feature extends the ASP.NET Core cookie authentication handler to maintain a user’s authentication session state in a server-side store, rather than putting it all into a self-contained cookie. Using server-side sessions enables more architectural features in your IdentityServer, such as:

  • query and manage active user sessions (e.g. from an administrative app).
  • detect session expiration and perform cleanup, both in IdentityServer and in client apps.
  • centralize and monitor session activity in order to achieve a system-wide inactivity timeout.

License: Lite, Standard, Advanced, Custom

The Duende Backend For Frontend (BFF) security framework packages up guidance and the necessary components to secure browser-based frontends (e.g. SPAs or Blazor WASM applications) with ASP.NET Core backends.

License: Business (legacy), Enterprise (legacy), Standard, Advanced, Custom

Implementation of RFC 8707. Provides a standards-based endpoint to register clients and their configuration.

License: Business (legacy), Lite, Standard, Advanced, Custom

Implementation of RFC 9126. Provides a more secure way to start a browser-based token/authentication request.

License: Enterprise (legacy), Advanced, Custom

The dynamic configuration feature allows dynamic loading of configuration for OpenID Connect providers from a store. This is designed to address the performance concern and allowing changes to the configuration to a running server.

License: Enterprise (legacy), Standard, Advanced, Custom

The resource isolation feature allows a client to request access tokens for an individual resource server. This allows API-specific features such as access token encryption and isolation of APIs that are not in the same trust boundary.

Client-Initiated Backchannel Authentication (CIBA)

Section titled “Client-Initiated Backchannel Authentication (CIBA)”

License: Enterprise (legacy), Standard, Advanced, Custom

Duende IdentityServer supports the Client-Initiated Backchannel Authentication Flow (also known as CIBA). This allows a user to log in with a higher security device (e.g. their mobile phone) than the device on which they are using an application (e.g. a public kiosk). CIBA is one of the requirements to support the Financal-grade API compliance.

Proof-of-Possession At The Application Layer / DPoP

Section titled “Proof-of-Possession At The Application Layer / DPoP”

License: Enterprise (legacy), Standard, Advanced, Custom

A mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens.

License: Enterprise (legacy), Standard (add-on), Advanced, Custom

IdentityServer can act as a SAML 2.0 Identity Provider (IdP), issuing SAML assertions to Service Providers (SPs) that use the SAML 2.0 protocol rather than OAuth 2.0 / OpenID Connect. This is useful for integrating with enterprise SaaS applications (e.g. Salesforce, ServiceNow) or legacy SSO systems that require SAML-based federation.

Financial-Grade Security and Conformance (FAPI 2.0)

Section titled “Financial-Grade Security and Conformance (FAPI 2.0)”

License: Standard (add-on), Advanced (add-on), Custom (add-on)

The Financial-grade API (FAPI) 2.0 Security Profile is an API security profile based on OAuth 2.0 designed to protect APIs in high-value scenarios such as e-health and e-government. Duende IdentityServer implements the FAPI 2.0 best current practice features and includes a built-in conformance report that assesses your server and client configuration against OAuth 2.1 and FAPI 2.0 specifications.

A single deployment acts as a single OpenID Connect / OAuth authority hosted at a single URL. It can consist of multiple physical or virtual nodes for load-balancing or fail-over purposes.

Can be either completely independent single deployments, or a single deployment that acts as multiple authorities.

A single logical deployment that acts as multiple logical token services on multiple URLs or host names (e.g. for branding, isolation or multi-tenancy reasons).

Redistribution occurs when you bundle Duende IdentityServer as an integrated component of a product or service that you sell, lease, or provide to third parties.

Redistribution typically applies to Independent Software Vendors (ISVs) who ship IdentityServer as part of a larger solution that customers host on their own local or cloud infrastructure.

Each customer installation of IdentityServer is considered a separate redistribution.

The total of unique identity records stored in Duende User Management, identified by User Management user ID per billing period.

FIDO2 is the FIDO Alliance’s umbrella standard for strong, passwordless authentication. It encompasses two specifications: WebAuthn (the browser/platform API) and CTAP (Client to Authenticator Protocol, which defines how authenticators such as hardware security keys communicate with a platform). FIDO2 credentials are based on public-key cryptography and are phishing-resistant by design.

Multi-Factor Authentication requires a user to present two or more independent verification factors before being granted access. Factors are typically categorized as something you know (e.g. a password or PIN), something you have (e.g. a TOTP authenticator app or hardware key), and something you are (e.g. a biometric). Requiring multiple factors significantly reduces the risk of account compromise from stolen credentials.

A One-Time Password is a temporary, single-use code delivered out-of-band (typically via email or SMS) that authenticates a user without requiring a traditional password. Because each code is valid for only a short window and cannot be reused, OTPs provide a simple form of passwordless or second-factor authentication.

A passkey is a FIDO2 credential that replaces a traditional password. It is bound to a specific device (or synced across a user’s devices via a platform credential manager) and is unlocked locally using biometrics or a PIN. The private key never leaves the device, making passkeys resistant to phishing and server-side credential theft.

A recovery code is a one-time backup code generated at enrollment time and stored securely by the user. It can be used to regain account access when primary authenticators (such as a TOTP app or passkey device) are unavailable. Each code is valid for a single use only.

In Duende User Management, a space is the fundamental isolation unit. Each space has its own isolated user store, configuration, and authentication settings. This enables deployments where users, roles, and groups in one space are completely separated from those in another. A typical use case is supporting multiple tenants in a single deployment.

A Subject ID (sub) is a stable, unique identifier assigned to a user within the system. It is analogous to, and typically maps directly to, the sub claim in OpenID Connect tokens. The Subject ID remains constant across sessions and should be used as the canonical reference to a user rather than mutable attributes such as username or email address.

A Time-Based One-Time Password is a short-lived numeric code generated by an authenticator app (e.g. Google Authenticator, Microsoft Authenticator) according to RFC 6238. The code is derived from a shared secret and the current time, and is typically valid for 30 seconds. TOTP is widely used as a second factor in MFA flows.

WebAuthn is the W3C Web Authentication standard that defines a browser API for creating and using public-key credentials. It is the web-facing component of FIDO2. Relying parties (web applications) use WebAuthn to register and authenticate users with device-bound or synced credentials (passkeys), hardware security keys, or platform authenticators, all without transmitting a password.

Online developer community forum for Duende Software product issues and bugs.

License: Enterprise (legacy), Standard, Advanced, Custom

Helpdesk system with guaranteed response time for Duende Software product issues and bugs.