Accès

OAuth2 est un cadre de délégation d’autorisation : une application obtient un accès limité à une ressource au nom de quelqu’un, sans manipuler son mot de passe. OpenID Connect ajoute au-dessus l’identification : savoir qui est l’utilisateur. La distinction porte des conséquences directes sur la conception.

Le jeton d’accès sert à appeler l’API, il est destiné à l’API, et le client n’a pas à le lire. Le jeton d’identité décrit l’utilisateur authentifié, il est destiné à l’application cliente, jamais à l’API. Une API qui accepte un jeton d’identité comme autorisation a un défaut de conception, et il se détecte en lisant l’audience du jeton.

Qui prouve quoi

Trois questions se posent à chaque appel, et les confondre est l’erreur d’origine de la plupart des conceptions. L’authentification établit qui appelle. L’autorisation établit ce que cet appelant a le droit de faire. Et une troisième, souvent oubliée : pour le compte de qui, quand une application appelle au nom d’un utilisateur.

Une clé d’API ne répond qu’à la première, et partiellement : elle prouve que l’appelant détient la clé, pas qui il est. Elle ne désigne aucun utilisateur final et n’expire pas. C’est un identifiant de trafic, insuffisant dès qu’il y a une donnée à protéger.

Ce qu’elle apporte est ailleurs, et c’est le mécanisme central d’une plateforme d’API. La clé, ou le client OAuth, appartient à une application déclarée, et cette application a souscrit à des produits. La plateforme sait donc, avant même de regarder le jeton, quelles API cet appelant a le droit d’appeler et à quel volume. Un appel vers une API non souscrite est refusé sans que le service soit consulté, et le compteur de quota s’impute à la souscription, pas à l’adresse IP.

C’est ce qui sépare une plateforme d’API d’un proxy avec une liste de clés. Le test se pose à l’exploitant : quand un partenaire demande l’accès à une API supplémentaire, est-ce un formulaire de souscription qu’il remplit, ou un ticket qui aboutit à une ligne de configuration écrite à la main ? La deuxième réponse annonce un catalogue qui ne sera jamais à jour.

Le jeton d’accès répond aux trois. Dans sa forme la plus courante, c’est un jeton signé, un JWT : un objet lisible qui porte l’émetteur, l’audience, une date d’expiration et les portées accordées, avec une signature cryptographique qui permet de vérifier qu’il n’a pas été fabriqué. Le vérifier ne demande donc aucun appel réseau, et c’est cette propriété qui commande la suite.

Quel flux pour quel cas

Deux flux sont à écarter, et la RFC 9700 ne les met pas au même rang. Le flux mot de passe, où l’application manipule les identifiants de l’utilisateur, ne doit pas être utilisé, sans réserve. Le flux implicite, lui, est déconseillé : le jeton revient dans le fragment de l’URL de redirection, jamais transmis au serveur mais exposé à l’historique du navigateur et à l’injection d’un jeton dans la réponse d’autorisation. Les deux survivent surtout dans les configurations recopiées.

Le token exchange

Un utilisateur appelle l’API A, qui doit appeler l’API B pour le servir. Trois réponses existent.

Faire suivre le jeton de l’utilisateur donne à B un jeton dont l’audience désigne A, avec toutes les portées de l’utilisateur. Si B est compromis, ce jeton est utilisable ailleurs.

Appeler B avec un jeton de service fait disparaître l’utilisateur : l’audit et les décisions d’autorisation ne peuvent plus s’appuyer sur lui.

Le token exchange, normalisé par la RFC 8693, répond correctement. A obtient du fournisseur d’identité un jeton destiné à B, aux portées réduites, qui conserve l’identité d’origine.

Où valider le jeton

Client

Jeton d’accès

Gateway

Signature, expiration, audience, émetteur

Service

Autorisation métier, revalidation

Valider à la gateway seule laisse le backend sans défense le jour où un appel la contourne, et il finit par y en avoir. Valider au service seul multiplie les implémentations, et donc les erreurs : audience non vérifiée, algorithme accepté sans contrainte, clés jamais renouvelées.

La réponse robuste utilise les deux, avec des rôles distincts : authentification et portées à la gateway, qui rejette tôt et protège la capacité, autorisation métier dans le service, seul à savoir qui a le droit de voir quel dossier. Une gateway qui prend des décisions d’autorisation métier a récupéré de la logique qui ne lui appartient pas, voir la gateway.

La durée de vie du jeton, et la révocation

C’est la décision de conception la plus lourde de la page, et la moins débattue. Elle fixe trois choses d’un coup : la latence de chaque appel, le couplage au fournisseur d’identité, et le délai réel pour couper un accès.

Deux formes existent. Le jeton signé se vérifie localement, sans appel réseau, donc sans latence ajoutée ni dépendance à l’IdP sur le chemin de l’appel. Il reste valable jusqu’à son expiration, quoi qu’il arrive : rien ne peut l’annuler.

Le jeton opaque est une référence sans contenu, que le validateur doit soumettre à l’IdP par introspection, normalisée par la RFC 7662. Chaque appel devient tributaire de la disponibilité de l’IdP, mais la révocation est immédiate.

Le compromis qui tient dans la majorité des cas associe un jeton signé à durée courte, quelques minutes, et un jeton de rafraîchissement de longue durée détenu par le client. Le premier n’est jamais révoqué, il expire. Le second est révocable, et comme il ne sert qu’à intervalles espacés, l’interroger ne pèse pas sur le chemin de l’appel.

D’où le chiffre qu’il faut savoir énoncer : le délai réel pour couper un consommateur est la durée de vie du jeton d’accès. Une plateforme qui émet des jetons de huit heures ne peut pas promettre de couper un partenaire en moins de huit heures, quelle que soit la console. Si l’engagement contractuel ou réglementaire est plus court, il faut soit raccourcir la durée, soit ajouter une liste de révocation consultée à la gateway pour les seuls cas urgents.

Le réglage courant, à valider selon l’exposition : cinq à quinze minutes pour un jeton d’accès, quelques heures à quelques jours pour le rafraîchissement. Raccourcir davantage déplace simplement la charge sur l’IdP, qui devient alors le composant à dimensionner.

Les points de vigilance

L’audience. Un jeton émis pour l’API A ne doit pas être accepté par l’API B. Vérifier aud tient en une ligne de configuration. Son absence reste le défaut le plus répandu.

L’algorithme. Accepter l’algorithme annoncé dans l’en-tête du jeton est une faille documentée. La liste des algorithmes admis se fixe côté validation.

Le renouvellement des clés. Le cache JWKS doit se rafraîchir de lui-même, faute de quoi la plateforme rejette tous les jetons à la rotation suivante du fournisseur d’identité.

La tolérance d’horloge. Quelques secondes d’écart entre émetteur et validateur suffisent à rejeter des jetons valides. La tolérance se règle petite. Large, elle devient une faille.

La taille du jeton. Un jeton chargé de rôles peut dépasser la taille d’en-tête admise par un composant intermédiaire. La panne ne touche que les utilisateurs aux nombreux rôles, ce qui la rend longue à diagnostiquer.

La granularité des portées. Une portée unique sur toute la plateforme ne protège de rien, des centaines de portées ne sont plus attribuées correctement par personne. La maille utile est la ressource et l’opération.

mTLS

OAuth2 identifie l’appelant applicatif, le TLS mutuel identifie le canal. Les deux se combinent, et le mTLS reste le mécanisme attendu par défaut sur les flux partenaires à forte sensibilité, en particulier dans la banque et l’assurance.

Ses deux difficultés n’ont rien de cryptographique. Le cycle de vie des certificats d’abord, qui exige un inventaire, des alertes d’expiration et un préavis de renouvellement contractualisé. La terminaison ensuite : si un load balancer termine le TLS avant la gateway, l’identité du client doit lui être transmise par un canal fiable.

L’expiration d’un certificat partenaire est un incident courant, et sa particularité est d’être entièrement prévisible : la date est connue à l’émission.

Le filtrage et les limites

Avant toute question d’identité, deux défenses se posent à la gateway et coûtent presque rien. Elles sont aussi les plus souvent oubliées dans les configurations reprises d’un projet à l’autre.

Le filtrage par adresse IP. Restreindre l’origine du trafic à une liste connue. Sur un flux partenaire, sur une API d’administration, sur un back-office, c’est la mesure qui demande le moins de travail pour le plus d’effet. Elle ne remplace jamais l’authentification, parce qu’une adresse se falsifie et qu’un partenaire change d’infrastructure sans prévenir, mais elle réduit la surface avant que le premier jeton soit lu. La contrepartie est un inventaire à tenir, et une expiration à surveiller comme celle d’un certificat.

Les limites de débit, qui sont deux mécanismes distincts. La confusion entre les deux est fréquente et se paie en incidents.

Le spike arrest absorbe une rafale. Un client qui envoie mille appels en une seconde alors que le backend en tient cent est arrêté avant d’avoir fait tomber le service, et le reste des consommateurs ne s’en aperçoit pas. Le quota, lui, dit qu’une souscription a droit à un million d’appels par mois, ce qui n’a rien à voir avec la capacité et tout à voir avec ce qui a été vendu.

Une plateforme qui n’a que le quota laisse passer les rafales. Une plateforme qui n’a que le spike arrest ne sait pas facturer ni départager deux consommateurs. Les deux se posent, et le refus renvoie un code 429 avec un en-tête qui dit quand réessayer, faute de quoi le client réessaie immédiatement et aggrave ce que la limite devait éviter.

Ce que la gateway protège, et ce qu’elle ne protège pas

L’OWASP API Security Top 10 recense les risques propres aux API. Sa lecture utile est de trier ce qui se traite à la gateway de ce qui ne s’y traite pas.

Les défauts d’autorisation, les plus exploités du lot, se traitent dans le code et se vérifient en test. L’achat d’une plateforme n’y change rien.

La gateway couvre en revanche bien les risques de volume et de configuration. Quatre défenses s’activent dès le départ : spike arrest et quota comme décrit plus haut, validation de schéma en entrée avec refus des propriétés inconnues, limites de taille et de profondeur des corps, et messages d’erreur qui ne révèlent ni pile technique ni requête interne.

Le cas GraphQL

Une seule route, un corps qui décrit une requête arbitraire : le rate limiting par appel perd son sens quand un appel peut coûter mille fois plus qu’un autre. Et si POST est le verbe obligatoire, la spécification autorise GET pour les lectures, ce qui suffit à faire passer du trafic à côté d’une protection posée sur le seul POST.

Les protections spécifiques se posent donc explicitement : profondeur maximale, analyse de coût, introspection désactivée en production, requêtes pré-enregistrées pour les clients connus. Une gateway qui annonce le support de GraphQL se limite souvent à le router. La liste ci-dessus fait un bon questionnaire d’avant-vente.