OAuth, JWT e gateway: separare i controlli di sicurezza

Scegliere il ruolo prima dello strumento

Un token di accesso OAuth può essere opaco o usare JWT. Decodificare JWT non ne verifica l’autenticità; un JWT firmato non cifra automaticamente il contenuto. Un gateway non sostituisce l’autorizzazione applicativa nei servizi.

Verificare protocollo e ogni accesso

• Scegliete un flusso adatto al client. Per percorsi utente seguite le raccomandazioni attuali su codice di autorizzazione e PKCE, con libreria mantenuta e reindirizzamenti controllati rigorosamente.
• Per un JWT accettato verificate firma, algoritmi consentiti, emittente, destinatario e vincoli temporali del profilo. Rifiutate token destinati ad altri usi.
• Controllate ogni oggetto, azione e organizzazione. Testate accessi fra account con dati fittizi; un ruolo o ambito generale non sempre basta.

Prevedere scadenza, revoca e incidenti

Documentate rinnovo, rotazione delle chiavi, perdita di segreti e strategia di revoca. La verifica locale non apprende automaticamente una revoca remota. Limitate dati e registri; né JWT né quote garantiscono da soli sicurezza o conformità.

Fonti primarie

• IETF RFC 9700 — OAuth 2.0 Security Best Current Practice [EN]
• IETF RFC 8725 — JWT Best Current Practices [EN]
• OpenID Foundation — OpenID Connect Core 1.0 [EN]
• OWASP — Authorization Cheat Sheet [EN]

{
    "old_origin": "https://login.old.example",
    "old_rp_id": "old.example",
    "new_origin": "https://login.new.example",
    "new_rp_id": "new.example",
    "same_service_account": true,
    "expected": "authenticated_new_registration"
}

{
    "issuance_succeeded": true,
    "proxy_count": 2,
    "proxies_serving_expected_certificate": 1,
    "other_proxy_certificate_expired": true,
    "tls_verification_enabled": true,
    "expected": "change_incomplete_fix_and_verify_client_paths"
}