Ressources · 43
OAuth et OpenID Connect : vérifier une intégration de bout en bout
Distinguer connexion, délégation et droits sur les données, puis tester redirections, jetons, sessions et révocation.
· 4 min
Ce que ce guide permet
- Séparer identité et autorisation
- Éviter une redirection ou un jeton accepté à tort
- Tester les refus aussi précisément que les succès
- Vérifier la fin des accès après départ ou incident
Contrôle express
- Quel fournisseur et quel émetteur sont attendus ?
- L’URI de retour est-elle enregistrée précisément ?
- Un ID token est-il utilisé à tort comme access token ?
- Chaque ressource vérifie-t-elle son propriétaire ?
- Quels accès restent actifs après révocation ?
Méthode pas à pas
- 01
Dessiner le flux réel
Identifiez client public ou confidentiel, navigateur, serveur d’autorisation, API et fournisseur OIDC. Notez où les codes et jetons circulent, qui les conserve et quels rôles sont accordés. Un diagramme commercial ne suffit pas à décrire le déploiement réel.
Livrable : flux, frontières de confiance et propriétaire de chaque composant.
- 02
Contrôler la transaction de connexion
Utilisez le flux code avec PKCE adapté au client. Vérifiez S256, liaison à la transaction, URI enregistrée et protection contre les requêtes forgées. Testez une URI non prévue, un vérificateur incorrect, un code rejoué et un émetteur inattendu. La RFC 9700 distingue exigences et recommandations selon le type de client.
Livrable : cas de test et résultats autorisés/refusés.
- 03
Valider le jeton au bon endroit
L’API vérifie le jeton d’accès selon son format et les règles du fournisseur : signature ou introspection, émetteur, audience, expiration et droits. Le client OIDC valide séparément le jeton d’identité. Une signature valide ne prouve pas qu’un jeton est destiné à cette API.
Livrable : contrat de validation et tests d’audience et de date.
- 04
Vérifier les droits métier
Testez un objet d’un autre compte, un rôle inférieur, un champ privé et une action d’administration. La présence d’un scope ou d’une passerelle authentifiée ne remplace pas le contrôle serveur sur la ressource demandée. Utilisez des comptes et données de test autorisés.
Livrable : matrice rôle, objet, opération et refus attendu.
- 05
Exercer expiration et révocation
Distinguez session locale, session du fournisseur, access token et refresh token. Testez départ, appareil perdu, changement de rôle, rotation des clés et indisponibilité du fournisseur. Documentez le délai résiduel d’accès au lieu de supposer que déconnexion signifie révocation immédiate.
Livrable : chronologie de perte d’accès et exceptions.
- 06
Observer sans exposer les secrets
Journalisez identifiant de transaction, décision de validation, catégorie d’erreur et version de configuration. Excluez codes, jetons et secrets. Préparez diagnostic, arrêt de l’intégration et retour à une configuration validée ; rejouez les tests après changement du fournisseur.
Livrable : procédure d’exploitation et contrôle de non-régression.
Exemple d’application
Situation illustrative
Situation illustrative : deux clients utilisent le même fournisseur d’identité. Un jeton valide pour le premier est présenté à l’API du second.
Décision et preuve attendue
L’API refuse l’audience incorrecte, conserve une trace sans jeton et ne renvoie aucune donnée. Ce refus devient un test de régression.
Distinguer les mécanismes
| Mécanisme | Utilité | Point de vigilance |
|---|---|---|
| OAuth 2.0 | Déléguer l’accès à une ressource | Contrôle serveur des droits sur l’objet |
| OpenID Connect | Établir l’identité avec un ID token validé | Validation de l’émetteur, audience et transaction |
| Session applicative | Maintenir la connexion à l’application | Expiration, invalidation et protection de la session |
Indicateurs de pilotage
| Indicateur | Ce qu’il mesure | Première action |
|---|---|---|
| Refus corrects | Cas interdits effectivement bloqués | Corriger chaque acceptation inattendue |
| Délai de révocation | Temps jusqu’à disparition des accès concernés | Vérifier sessions et jetons séparément |
| Erreurs de validation | Rejets par cause et version | Distinguer attaque et mauvaise configuration |
Erreurs fréquentes
- Confondre authentification et autorisation
- Accepter toute audience après vérification de signature
- Enregistrer une URI de retour trop large
- Journaliser les jetons pour faciliter le débogage
Questions fréquentes
PKCE remplace-t-il tous les contrôles ?
Non. Il protège l’échange du code dans le flux prévu ; validation des jetons, redirections, autorisation métier et sessions restent à vérifier.
Un JWT est-il une permission ?
JWT est un format. Les revendications ne deviennent utilisables qu’après validation et application des règles de votre API.
Faut-il développer soi-même la validation ?
Préférez une bibliothèque maintenue et la documentation du fournisseur, puis testez votre configuration. Une bibliothèque correcte peut être mal paramétrée.
Références officielles
Pour aller plus loin
