Token Encryption

ProAuth can return encrypted JWTs for access tokens, ID tokens, and UserInfo responses. Encrypted tokens use compact JWE serialization and contain an inner signed JWT. This hides token contents from browsers, proxies, logs, and other intermediaries while preserving signature validation after decryption.

Client Configuration

Configure encryption on the ClientApp:

Setting	Description
Access Token Encryption Enabled Override	Optional per-client override. Empty inherits the tenant default. true encrypts self-contained access tokens. Reference access tokens remain opaque handles.
ID Token Encrypted Response Alg	JWE key management algorithm for ID tokens.
ID Token Encrypted Response Enc	JWE content encryption algorithm for ID tokens.
UserInfo Encrypted Response Alg	JWE key management algorithm for UserInfo JWT responses.
UserInfo Encrypted Response Enc	JWE content encryption algorithm for UserInfo JWT responses.
Introspection Encrypted Response Alg	JWE key management algorithm for encrypted JWT introspection responses.
Introspection Encrypted Response Enc	Optional JWE content encryption algorithm for encrypted JWT introspection responses. If omitted while the introspection alg is configured, ProAuth uses A128CBC-HS256 as defined by RFC 9701.
Client App Key Sets	One or more key sets with usage TokenEncryption. Use these to provide the client's encryption keys.

ID token and UserInfo encryption are enabled when both alg and enc are configured and ProAuth can resolve a matching client encryption key from Client App Key Sets. JWT introspection response encryption is enabled when Introspection Encrypted Response Alg is configured. If encryption is configured but no usable key is available, ProAuth fails closed instead of returning plaintext.

Supported Algorithms

Key management algorithms:

• RSA-OAEP
• RSA-OAEP-256
• A128KW
• A256KW

Content encryption algorithms:

• A128CBC-HS256
• A256CBC-HS512
• A128GCM
• A256GCM

Symmetric key wrapping algorithms (A128KW, A256KW) require an InlineProtectedJwks key set with usage TokenEncryption. ProAuth does not load symmetric keys from a remote JWKS URI and never publishes client symmetric keys.

Remote encryption JWKS fetching uses the same enterprise remote-document policy as JWT client-authentication keys: HTTPS only, DNS resolution before fetch, no redirects, short timeout, response-size cap, and public-address-only targets. Use a directly registered JWK Set for private-network key material.

Example RSA encryption key set:

{
  "name": "Portal token encryption keys",
  "clientAppId": "10000000-0000-4000-8000-000000000010",
  "sourceType": "InlinePublicJwks",
  "usage": "TokenEncryption",
  "status": "Active",
  "jwksJson": "{\"keys\":[{\"kty\":\"RSA\",\"kid\":\"portal-enc-2026-01\",\"use\":\"enc\",\"alg\":\"RSA-OAEP-256\",\"n\":\"...\",\"e\":\"AQAB\"}]}"
}

Example protected symmetric key set for JWT introspection response encryption:

{
  "name": "Resource server introspection encryption key",
  "clientAppId": "10000000-0000-4000-8000-000000000020",
  "sourceType": "InlineProtectedJwks",
  "usage": "TokenEncryption",
  "status": "Active",
  "protectedJwksJson": "{\"keys\":[{\"kty\":\"oct\",\"kid\":\"rs-enc-2026-01\",\"use\":\"enc\",\"alg\":\"A256KW\",\"k\":\"...\"}]}"
}

Resource Server Integration

APIs that receive encrypted self-contained access tokens can either decrypt and validate the inner signed JWT with the client-held private/symmetric key, or use ProAuth token introspection. Introspection resolves encrypted access tokens by the token hash stored by ProAuth and returns the same payload data as for signed JWT access tokens.

Reference access tokens are unchanged by access-token encryption settings. The client still receives an opaque handle, and APIs validate it through introspection.

JWT Introspection Responses

ProAuth supports RFC 9701 JWT responses at the token introspection endpoint. The default RFC 7662 JSON response is unchanged. To request a signed JWT response, the resource server sends:

POST /connect/introspect HTTP/1.1
Host: idp.example.com
Accept: application/token-introspection+jwt
Content-Type: application/x-www-form-urlencoded

token=<access-token>&client_id=<resource-server-client-id>&client_secret=<secret>

The response content type is application/token-introspection+jwt. The JWT is signed with the ProAuth authorization-server signing key and uses the typ header value token-introspection+jwt.

The JWT payload contains wrapper claims and a nested token_introspection object:

{
  "iss": "https://idp.example.com",
  "aud": "<resource-server-client-id>",
  "iat": 1800000000,
  "token_introspection": {
    "active": true,
    "scope": "openid profile",
    "client_id": "<token-client-id>",
    "sub": "<subject>",
    "exp": 1800003600,
    "iat": 1800000000,
    "nbf": 1800000000,
    "aud": ["api://orders"],
    "iss": "https://idp.example.com",
    "jti": "<token-id>"
  }
}

Resource servers must validate the JWT signature with the ProAuth discovery jwks_uri, check the issuer, check the audience, and require the typ header to be token-introspection+jwt. If the token is inactive or not intended for the authenticated resource server, ProAuth returns a signed JWT whose token_introspection object contains only { "active": false }.

To encrypt JWT introspection responses, configure Introspection Encrypted Response Alg and provide a client app key set with usage TokenEncryption. ProAuth signs the JWT first and then encrypts it as a nested JWE.

Discovery And JWKS

The discovery document advertises supported ID token, UserInfo, and introspection response signing/encryption algorithms. The ProAuth JWKS endpoint includes ProAuth encryption public keys with use: enc for server-issued encrypted internal tokens. Client encryption keys remain configured on each ClientApp.