Duende IdentityServer v8 introduces a clearer way to think about OpenID Connect and OAuth protocol support: Core and Extended. Every license tier ships with the core protocols. Extended protocols unlock capabilities for teams with specialized integration needs, advanced security requirements, or non-browser device flows.

This post breaks down what’s in each category, why the split exists, and which business scenarios push you from core into extended territory.

What Are Core Protocols?

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:

That’s a lot of ground covered. 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.

What Are Extended Protocols?

Extended protocols address requirements that go beyond typical web and API scenarios. They’re available in the Standard tier and above, but not in the Lite tier.

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

When Do You Need Core Protocols?

Short answer: always. Core protocols are the baseline for any identity and access management deployment. Here are the business scenarios they cover directly:

Web applications with user login. Authorization code flow with PKCE handles interactive sign-in for server-rendered apps, SPAs (through the Duende BFF Security Framework), and mobile apps. OIDC Discovery means your clients auto-configure themselves against your IdentityServer instance.

API-to-API communication. The client credentials flow gives your backend services a straightforward way to obtain tokens and call protected APIs. No user involvement, no browser, just tokens.

Microservice architectures. Token exchange lets Service A swap its token for one that Service B accepts, crossing trust boundaries without sharing credentials.

Token security without extra infrastructure. DPoP and PAR are core in version 8. DPoP binds access tokens to a cryptographic key, rendering intercepted tokens useless to an attacker. PAR moves authorization parameters out of the browser’s address bar, reducing exposure. These used to be enterprise-tier features. Now they’re available to every IdentityServer version 8 customer.

Clean session management. The full logout suite (RP-Initiated, Front-Channel, Back-Channel) means your users can sign out of one app and have their session end across all apps. No orphaned sessions, no stale tokens.

When Do You Need Extended Protocols?

Extended protocols come into play when your business requirements go beyond standard browser-based flows or when you’re operating in environments with heightened security or integration complexity.

flowchart TD
    A[Your Application] --> B{Browser-based login?}
    B -->|Yes| C[Core: Authorization Code + PKCE]
    B -->|No| D{Device with no browser?}
    D -->|Yes| E[Extended: Device Authorization Grant]
    D -->|No| F{Backend-triggered auth?}
    F -->|Yes| G[Extended: CIBA]
    F -->|No| H{Certificate-bound tokens required?}
    H -->|Yes| I[Extended: mTLS]
    H -->|No| J[Core protocols cover your needs]

    style C fill:#2d6a4f,color:#fff
    style J fill:#2d6a4f,color:#fff
    style E fill:#e76f51,color:#fff
    style G fill:#e76f51,color:#fff
    style I fill:#e76f51,color:#fff

mTLS: High-Security API Ecosystems

Business scenario: You’re in financial services, healthcare, or government, and your API consumers must prove their identity at the transport layer, not just the application layer.

mTLS binds tokens to a client’s TLS certificate. Even if an attacker steals a token, it’s useless without the matching certificate. This is a hard requirement in many regulated environments, especially those aligning with FAPI 2.0.

JAR: Tamper-Proof Authorization Requests

Business scenario: You need to guarantee that the authorization request a user’s browser sends hasn’t been modified in transit.

JAR wraps the entire authorization request in a signed (and optionally encrypted) JWT. It’s relevant when you’re building open banking integrations, partnering with financial institutions, or operating in any context where the integrity of authorization requests is non-negotiable.

Resource Indicators: Multi-API Token Targeting

Business scenario: You run multiple distinct APIs behind a single IdentityServer, and you need tokens scoped to a specific API rather than broadly usable.

Resource indicators (RFC 8707) allow a client to specify “I want a token for this specific API” in the authorization request. That’s useful when you’re an ISV with multiple product APIs, or when you need to enforce strict audience restrictions across a service mesh.

CIBA: Authentication Without a Browser

Business scenario: A call center agent needs to authenticate a customer over the phone. A point-of-sale terminal needs to verify a user’s identity. A backend workflow needs to trigger authentication on a user’s mobile device.

CIBA flips the authentication model. Instead of the user initiating login in a browser, a backend system requests authentication, and the user confirms on a separate device. Financial services and telecom companies use this pattern for customer verification workflows where no browser is available.

Device Authorization Grant: Browserless Devices

Business scenario: You’re shipping smart TVs, CLI developer tools, IoT gateways, or kiosk devices that need to authenticate users but don’t have a browser or a usable keyboard.

The device authorization grant shows the user a code, they visit a URL on their phone or laptop, enter the code, and the device gets its tokens. It’s the same pattern Netflix and YouTube use for TV sign-in. If you’re building for devices with limited input capabilities, this is the protocol.

DCR: Self-Service Client Onboarding

Business scenario: You’re a platform provider, and your customers or partners need to register their own OAuth 2.0 clients without filing a support ticket.

Dynamic Client Registration lets applications register programmatically. That’s valuable for API marketplaces, multi-tenant SaaS platforms, and partner ecosystems where manual client provisioning doesn’t scale.

How This Maps to IdentityServer v8 License Tiers

The protocol split aligns directly with the version 8 licensing model:

The Lite tier gives you full core protocol support for small deployments (2 client IDs, 1 deployment, 10,000 User Management users). If your use case stays within standard web and API patterns, Lite covers it.

The moment your business needs mTLS, CIBA, device flows, DCR, JAR, or resource indicators, you’re looking at Standard or above.

Choosing Your Path

Start by mapping your actual requirements:

1. Are you building web apps and APIs with browser-based login? Core protocols. Start with Lite or Standard, depending on scale.
2. Do you need to support IoT, smart TV, or CLI device login? You need the Device Authorization Grant. Standard or above.
3. Are you in a regulated industry that mandates certificate-bound tokens? mTLS is your path. Pair it with the Financial Grade Security and Conformance add-on for FAPI 2.0 compliance.
4. Do you need backchannel authentication for call center or POS workflows? CIBA. Standard or above.
5. Are you building a platform where partners register their own clients (via Dynamic Client Registration)? Standard or above.

Most teams start with core and grow into extended protocols as their platform matures and their integration requirements expand. The version 8 licensing model is designed for that progression.

Get Started

Explore the full protocol support matrix and licensing details in the IdentityServer documentation. If you’re upgrading from IdentityServer 7, the extended protocol split is one of the key changes to evaluate during your migration planning.