OAuth and OIDC enhanced security features

This page describes OAuth and OIDC security extensions that harden authorization requests, token issuance, and token usage.

JAR: JWT-secured authorization requests

JAR lets a client package authorization request parameters in a signed (and optionally encrypted) JWT, called a Request Object, instead of placing parameters directly in the query string.

The Request Object is either:

Passed by value. included directly in the request query parameter.
Passed by reference (not supported). Hosted at a URI included in the request_uri parameter (the server fetches it).

GET /authorize
  ?client_id=my-app
  &request=eyJhbGciOiJSUzI1NiIsInR5cCI6Imp3dCJ9...

note

The JWT payload includes standard authorization parameters (response_type, scope, redirect_uri, state, nonce, and so on).
The JWT must be signed.
Encryption is optional and recommended for sensitive parameters.
The authorization server validates the signature using the client's registered public key (JWKS).
When used with PAR, the Request Object is uploaded server-side before browser redirection.

PAR: pushed authorization requests

PAR lets the client push the full authorization request to the authorization server over a direct back-channel (HTTPS POST) before redirecting the user. The server returns a short-lived request_uri used during browser redirection.

Step 1 - Push the request (back-channel)

POST /as/par HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded

client_id=my-app
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
&client_assertion=<signed-JWT>
&response_type=code
&scope=openid profile
&redirect_uri=https://app.example.com/callback
&state=abc123
&code_challenge=...
&code_challenge_method=S256

Response

{
  "request_uri": "urn:ietf:params:oauth:request_uri:6esc_11ACC5bwc014ltc14eY",
  "expires_in": 60
}

Step 2 - Redirect with only request_uri

GET /authorize
  ?client_id=my-app
  &request_uri=urn:ietf:params:oauth:request_uri:6esc_11ACC5bwc014ltc14eY

note

Combining PAR and JAR is a strong option because the pushed payload contains a signed Request Object.

DPoP: demonstrating proof of possession

DPoP binds an access token (and refresh token) to a specific client key pair, making a stolen token unusable without the corresponding private key.

The client generates a fresh key pair (for example, ES256) and signs a DPoP proof JWT for each request.

DPoP proof JWT header

{
  "typ": "dpop+jwt",
  "alg": "PS256",
  "jwk": {
    "kty": "RSA",
    "e": "AQAB",
    "n": "...",
    "kid": "my-key",
    "alg": "RS256",
    "use": "sig"
  }
}

DPoP proof JWT payload

{
  "jti": "unique-id",
  "htm": "POST",
  "htu": "https://auth.example.com/token",
  "iat": 1717862400,
  "exp": 1717862460
}

Token request

POST /token HTTP/1.1
DPoP: <DPoP-Proof-JWT>

grant_type=authorization_code&code=...

Protected API request

GET /api/resource HTTP/1.1
Authorization: DPoP <access-token>
DPoP: <new-DPoP-Proof-JWT-for-this-request>

The resource server verifies:

The DPoP proof signature and key thumbprint binding.
The htm and htu values against the active request.
A recent iat.
A unique jti (optional but recommended replay protection).

OAuth 2.0 authorization server issuer identification

RFC 9207 addresses attacks where a client is tricked into sending an authorization code or token to the wrong authorization server.

The authorization server includes an iss parameter in the authorization response so the client can verify source identity.

GET /callback
  ?code=SplxlOBeZQQYbYS6WxSbIA
  &state=af0ifjsldkj
  &iss=https://auth.example.com

The client must:

Verify iss matches the expected issuer.
Reject the response if iss is missing (when RFC 9207 is supported) or does not match.

The authorization server metadata advertises support:

{
  "issuer": "https://auth.example.com",
  "authorization_response_iss_parameter_supported": true
}

RSA-PSS signing algorithms

RSA-PSS is a modern RSA signature scheme preferred over PKCS#1 v1.5 in high-security deployments.

RSA-PSS algorithm	Hash	Typical use
`PS256`	SHA-256	Recommended default RSA-PSS option for broad compatibility
`PS384`	SHA-384	Higher assurance profiles and stricter crypto policies
`PS512`	SHA-512	Specialized high-assurance environments

When using RSA-PSS algorithms in IDaaS:

Prefer PS256 for RSA-based signing unless policy requires PS384 or PS512.
Confirm both sides support PS* algorithms before enabling them.
Publish and rotate RSA public keys through JWKS URI or JWK/JWKS JSON.
Keep algorithm policy consistent across token signing, JAR, and client authentication.
Validate alg, kid, and key type (kty: RSA) during verification.

Elliptic curve keys and signing algorithms

Elliptic Curve Cryptography (ECC) provides strong signatures with smaller key sizes than RSA.

EC curve	JWA algorithm	Typical use
`P-256`	`ES256`	Recommended default for OIDC token signing and DPoP proofs
`P-384`	`ES384`	Higher security margin where stronger policy is required
`P-521`	`ES512`	Niche high-assurance deployments with strict crypto policy

When using EC keys and algorithms in IDaaS:

Prefer ES256 unless policy requires larger curves.
Ensure the same algorithm is configured on both sides.
Publish EC public keys in JWKS URI or JWK/JWKS JSON for Private Key JWT and JAR.
Rotate signing keys regularly and retain prior public keys during transitions.
Validate alg, kid, and key type (kty: EC) during verification.

References

For token and claim validation requirements, see OAuth and OIDC token validation and best practices.

JAR: JWT-secured authorization requests​

PAR: pushed authorization requests​

DPoP: demonstrating proof of possession​

OAuth 2.0 authorization server issuer identification​

RSA-PSS signing algorithms​

Elliptic curve keys and signing algorithms​

References​

Related topics​