ASP.NET Core Resource Server

ProAuth v3 includes ProAuth.Oidc.ResourceServer.AspNetCore for ASP.NET Core APIs that consume ProAuth access tokens. The package validates normal bearer JWTs and can additionally enforce sender-constrained access tokens, encrypted access tokens, and reference tokens.

Use this package for customer APIs that need the same resource-server behavior as the built-in Management API v2 and User Store API v2.

Package Setup

builder.Services.AddResourceServerAuthentication(
    builder.Configuration,
    options =>
    {
        options.Authority = "https://idp.example.com/";
        options.Audience = "my-api";
        options.AccessTokenPresentationPolicy = AccessTokenPresentationPolicy.BearerAndSenderConstrained;
    });

The authentication scheme name is Bearer, so existing ASP.NET Core [Authorize] policies and AuthenticationSchemes = "Bearer" continue to work.

Presentation Policies

Policy	Behavior
BearerOnly	Accepts legacy bearer tokens only. DPoP presentation is rejected.
BearerAndSenderConstrained	Accepts unbound bearer tokens and also accepts DPoP or certificate-bound tokens when the required proof is present. This is the v3 default for ProAuth-owned APIs.
SenderConstrainedRequired	Rejects unbound bearer tokens. DPoP-bound or certificate-bound tokens are accepted with proof.
DpopRequired	Requires DPoP-bound access tokens and a valid DPoP proof header.
CertificateBoundRequired	Requires an access token with cnf.x5t#S256 and a matching client certificate.

In hybrid mode, a token that contains cnf.jkt cannot be used as plain bearer, and a token that contains cnf.x5t#S256 must match the caller certificate.

DPoP Replay Store

DPoP proof replay detection is mandatory. The package includes:

• MemoryDpopProofReplayStore for development and single-process APIs.
• DistributedCacheDpopProofReplayStore for APIs that already use IDistributedCache.
• IDpopProofReplayStore for custom stores.

ProAuth-owned APIs adapt the existing ReaFx/database DPoP replay store and set ResourceServer:Dpop:ReplayStore to Custom.

Reference And Encrypted Tokens

Readable JWT access tokens are validated locally. JWE access tokens are decrypted when decryption keys are configured. Opaque/reference tokens are resolved through IAccessTokenIntrospectionClient.

For standalone APIs, configure RFC 7662 introspection:

{
  "ResourceServer": {
    "Introspection": {
      "Enabled": true,
      "Endpoint": "https://idp.example.com/connect/introspect",
      "ClientId": "api-introspection-client",
      "ClientSecret": "<secret>"
    }
  }
}

JWT introspection responses are supported when validation parameters are supplied for the introspection response issuer, audience, signing keys, and optional decryption keys.

ProAuth API Defaults

Management API v2 and User Store API v2 use:

{
  "ResourceServer": {
    "AccessTokenPresentationPolicy": "BearerAndSenderConstrained",
    "Dpop": {
      "ProofTimeWindow": "00:05:00",
      "ReplayStore": "Custom"
    },
    "Introspection": {
      "Enabled": true
    },
    "TokenDecryption": {
      "Enabled": true
    }
  }
}

This preserves existing bearer-token integrations while allowing ProAuth-owned clients and upgraded customer clients to use DPoP or certificate-bound tokens.

Migration Path

1. Deploy APIs in BearerAndSenderConstrained.
2. Enable FAPI 2.0 and DPoP for the Admin App/BFF with a persistent DPoP private JWK.
3. Enable DPoP for CLI profiles with proauthcli login --dpop or proauthcli loginservice --dpop.
4. Move customer integrations to the ProAuth client libraries or to another DPoP-capable client.
5. Change API policy to SenderConstrainedRequired or DpopRequired only after legacy integrations have migrated.

Use BearerOnly when an older environment cannot yet send DPoP proofs or client certificates.