OAuth, JWT et passerelles : séparer les contrôles de sécurité

Choisir un rôle avant un outil

Un jeton d’accès OAuth peut être opaque ou utiliser JWT. Décoder un JWT ne vérifie pas son authenticité ; un JWT signé ne chiffre pas automatiquement son contenu. La présence d’une passerelle ne remplace pas l’autorisation métier dans les services.

Vérifier le protocole et chaque accès

• Choisissez un flux adapté au client. Pour un parcours utilisateur, utilisez les recommandations actuelles sur le flux code et PKCE, avec une bibliothèque maintenue et des redirections strictement contrôlées.
• Pour un JWT accepté, vérifiez signature, algorithmes autorisés, émetteur, destinataire et contraintes temporelles prévues par le profil. Refusez un jeton destiné à un autre usage.
• Contrôlez l’accès à chaque objet, action et organisation. Testez les accès croisés entre comptes avec des données fictives ; un rôle ou une portée générale ne suffit pas toujours.

Prévoir aussi expiration, révocation et incidents

Documentez renouvellement, rotation des clés, perte de secrets et stratégie de révocation. Une vérification locale d’un jeton ne prend pas automatiquement connaissance d’une révocation distante. Limitez les données du jeton et les journaux ; ni JWT ni quota ne garantit à lui seul sécurité ou conformité.

Références primaires

• 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"
}