Using Open.IdentityServer for OpenID Connect in an Aspire setup
Damien Bowden wires Rock Solid Knowledge's Open.IdentityServer together with ASP.NET Core Identity to stand up an OpenID Connect provider inside an Aspire solution. The sample pairs a confidential web client using Authorization Code Flow, PKCE, PAR and client assertions with a protected Web API.
Key points
- Open.IdentityServer runs as the identity provider in an Aspire solution alongside ASP.NET Core Identity
- The web client uses Authorization Code Flow with PKCE, required OAuth PAR and client assertions
- PAR-based flows hook OnPushAuthorization and OnAuthorizationCodeReceived instead of redirect handlers
- The auth cookie is __Host-Http-ui-web with SameSite=Lax and tokens are kept via SaveTokens
- loa, loi and email claims come from UserInfo with MapInboundClaims disabled
- OAuth DPoP and CIBA are not implemented yet
The sample is orchestrated by Aspire and has three parts: an identity provider built on Open.IdentityServer, an ASP.NET Core web application and a protected Web API. The web app acts as a confidential client using Authorization Code Flow with PKCE, forces OAuth PAR (Pushed Authorization Requests) and authenticates with a JWT bearer client assertion instead of a client secret. The flow-specific work lives in a dedicated OpenIdConnect events class, with handlers on OnAuthorizationCodeReceived and OnPushAuthorization, which also forwards acr_values when present. The authentication cookie is named __Host-Http-ui-web with SameSite set to Lax, tokens are persisted through SaveTokens, and claims such as loa, loi and email are pulled from the UserInfo endpoint and mapped explicitly while MapInboundClaims is disabled. The API relies on delegated access tokens issued by Open.IdentityServer. The author notes that DPoP and CIBA are the notable standards not yet implemented and points to a migration guide from Duende.
Real-world use
- Teams that need a real OpenID Connect server behind a multi-service Aspire solution during local development
- Enterprise apps that want client assertions instead of shared secrets for client authentication
- High-security scenarios that require pushed authorization requests so request parameters leave the browser URL
- Identity teams evaluating a migration path from Duende IdentityServer to an alternative
Why it matters
Running the identity layer inside Aspire lets you exercise real OpenID Connect and OAuth flows locally against an actual provider, with hardening such as PAR and client assertions demonstrated in code.