JAR (JWT-Secured Authorization Request)

JAR (JWT-Secured Authorization Request, RFC 9101) est une extension OAuth 2.0 permettant de passer les paramètres authorization request dans un JWT signé (Request Object) au lieu de query string. Garantit intégrité (signature) et confidentialité (encryption optionnel) des authorization params.

Workflow :
(1) Client construit Request Object — JWT containing standard OAuth params (client_id, scope, redirect_uri, etc.) PLUS optional custom claims.
(2) Client signs JWT avec sa private key (and optionally encrypts).
(3) Client envoie via `/authorize` request — option `request=<JWT>` (passed by value) ou `request_uri=<URL hosting JWT>` (passed by reference, original JAR approach).
(4) IdP fetches/verifies JWT signature, optionally decrypts, extracts params, processes auth.

Avantages :
(1) **Integrity** — IdP knows params from client not tampered.
(2) **Client authentication** via signature key.
(3) **Confidentiality optional** via JWE encryption.
(4) **Compact** — can include many claims/scopes that would exceed URL length.
(5) **Foundation for FAPI** — Financial-grade API security.

Combiné avec PAR (recommended) :
- JAR signed request object pushed via PAR (server-to-server), referenced as request_uri in authorize redirect.
- Best security : integrity + confidentiality + no URL leakage.

Use cases :
(1) **FAPI 2.0** mandatory.
(2) **Open Banking** UK, EU, Brazil.
(3) **Healthcare HL7 FHIR**.
(4) **B2B integrations** with strict security.
(5) **High-value identity assertions**.

Library support :
- **node-openid-client** (Filip Skokan) — supports JAR/JARM/PAR/DPoP.
- **AppAuth-iOS, AppAuth-Android** — mobile.
- **Spring Security OAuth 2** — JAR support.
- **Auth0, Okta, ForgeRock, Curity** — IdP support.

Vs simple OAuth :
- Standard OAuth = params in URL (Bearer tokens).
- + PKCE = mitigates code interception.
- + JAR = signed authorization params.
- + PAR = backchannel push of authorization params.
- + DPoP = sender-constrained tokens.
- + JARM = signed response.
= Full FAPI 2.0 / Financial-grade security stack.

Most web apps don't need this — overkill. Banking, healthcare, gov DO need. Compétences SC-300, AZ-500.