OAuth 2.0 — JWT Bearer Assertion grant

Grant baseado em JWT assinado como assertion no token request. RFC 7523 §2.1.

Quando usar

SAP S/4HANA enterprise (chave privada registrada no provider)
Auth0 private_key_jwt (alternativa a client_secret pra grants confidential)
Azure AD on-behalf-of (OBO) — caller injeta JWT do usuário final

2 modos suportados

Modo A — Self-signed (mais comum)

Cliente possui chave privada RSA/EC. Lefia monta JWT (claims iss, sub, aud, iat, exp, jti) e assina antes de mandar pro token endpoint.

Campo	Detalhe
Token Endpoint	URL do `/oauth/token` do provider
Private Key (PEM)	Chave RSA ou EC. Aceita `\n` literal (form-friendly)
Issuer (iss)	Normalmente o `client_id`
Subject (sub)	Normalmente o `client_id` (M2M) ou user upn (OBO)
Audience (aud)	Default: token endpoint. Auth0 pede o audience da API
Key ID (kid, opcional)	Apontamento pra chave registrada no provider
Algoritmo	Default `RS256`. Suporta RS384, RS512, ES256, ES384, ES512

Modo B — Pré-fabricado (Azure AD OBO)

Caller já tem JWT do usuário (do flow de auth do app principal). Cole no campo JWT Assertion pronto. O Lefia só anexa ao body sem assinar — usa pro Azure AD OBO com requested_token_use=on_behalf_of.

Ciclo de vida

Token é cacheado em oauth_tokens (mesma tabela do Client Credentials). Refresh ocorre re-assinando novo JWT — não há refresh_token nesse grant.

Limitações

Não devolve refresh_token (JWT Bearer não precisa — basta re-assinar).
HS256 (chave simétrica) não é aceito — apenas assimétricos (RSA/EC).
Pra ES* keys o Lefia usa IEEE-P1363 encoding (formato JOSE) — Node default seria ASN.1 DER, incompatível.

Tickets relacionados

#194 implementação completa.

OAuth 2.0 — JWT Bearer Assertion (RFC 7523)