> For AI agents: [llms.txt](https://docs.trustedauth.com/llms.txt) provides a Markdown index of this documentation.

# 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).

```text
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)**

```http
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**

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

**Step 2 - Redirect with only `request_uri`**

```text
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**

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

**DPoP proof JWT payload**

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

**Token request**

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

grant_type=authorization_code&code=...
```

**Protected API request**

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

The resource server verifies:

1. The DPoP proof signature and key thumbprint binding.
2. The `htm` and `htu` values against the active request.
3. A recent `iat`.
4. 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.

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

The client must:

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

The authorization server metadata advertises support:

```json
{
  "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

- [OAuth 2.0 (RFC 6749)](https://datatracker.ietf.org/doc/html/rfc6749)
- [OAuth 2.1](https://oauth.net/2.1/)
- [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html)
- [Resource Server (RFC 8707)](https://www.rfc-editor.org/rfc/rfc8707.html)
- [OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR) (RFC 9101)](https://datatracker.ietf.org/doc/html/rfc9101)
- [OAuth 2.0 Pushed Authorization Requests (RFC 9126)](https://datatracker.ietf.org/doc/html/rfc9126)
- [OAuth 2.0 Demonstrating Proof of Possession (DPoP) (RFC 9449)](https://datatracker.ietf.org/doc/html/rfc9449)
- [OAuth 2.0 Authorization Server Issuer Identification (RFC 9207)](https://datatracker.ietf.org/doc/html/rfc9207)

## Related topics

For token and claim validation requirements, see [OAuth and OIDC token validation and best practices](/docs/applications-and-sso/oidc/oauth-oidc-foundations/oauth-oidc-token-validation-and-best-practices.md).