Identité et accès : authentification, autorisation, OAuth 2.0 et OpenID Connect

Authentification et autorisation

Chaque requête adressée à la plateforme de livraison de repas soulève deux questions distinctes. L’authentification demande qui est-ce ? et y répond par des preuves : un mot de passe, une passkey, un certificat, un jeton signé. L’autorisation demande l’appelant peut-il faire ceci, sur cet objet, maintenant ? et y répond par une politique : ce client peut lire cette commande parce qu’il l’a passée ; ce livreur peut voir cette adresse de retrait parce que la livraison lui est affectée. HTTP les distingue lui aussi : 401 Unauthorized signifie que la requête ne comporte pas d’authentification valide, tandis que 403 Forbidden signifie que l’appelant est connu mais n’a pas le droit d’agir.

Cette distinction compte sur le plan architectural, car les deux problèmes se résolvent à des endroits différents. L’authentification gagne à être centralisée dans un seul fournisseur d’identité (IdP) auquel toutes les applications font confiance, de sorte que les règles de mot de passe, l’authentification multifacteur, la récupération de compte et le verrouillage soient mis en œuvre une seule fois. L’autorisation est par nature distribuée : seul le service des commandes sait à qui appartient une commande, si bien que la décision finale concernant une commande doit être prise là, même si des vérifications grossières ont lieu plus tôt, au niveau de l’API gateway (passerelle d’API). La plupart des violations du contrôle d’accès recensées dans l’OWASP Top 10 viennent de la confusion entre les deux : un endpoint qui vérifie que le jeton est valide, puis renvoie n’importe quel objet dont on lui donne l’identifiant.

Mots de passe, authentification multifacteur et passkeys

Les mots de passe restent l’authentificateur le plus courant, et les Digital Identity Guidelines du NIST sont les règles les plus largement suivies en la matière. La révision 4 de la SP 800-63B, publiée en juillet 2025, renverse plusieurs habitudes de longue date. La longueur compte davantage que la composition : un mot de passe utilisé comme seul facteur doit compter au moins 15 caractères (au moins 8 lorsqu’il n’est utilisé que dans le cadre d’une authentification multifacteur), et les vérificateurs devraient accepter au moins 64 caractères, espaces et caractères Unicode compris. Les vérificateurs ne doivent pas imposer de règles de composition, comme l’obligation d’inclure un chiffre et un symbole, qui rendent les mots de passe plus difficiles à retenir sans les rendre beaucoup plus difficiles à deviner. Ils doivent vérifier les nouveaux mots de passe par rapport à une liste de blocage de mots de passe courants, prévisibles et compromis. Ils ne doivent pas imposer de changements périodiques, seulement un changement en cas de preuve de compromission. Ils doivent autoriser les gestionnaires de mots de passe et devraient autoriser le collage, ne doivent pas proposer d’indices de mot de passe lisibles avant la connexion et ne doivent pas demander de réponses à des questions de sécurité. Les tentatives échouées doivent faire l’objet d’une limitation de débit (rate limiting).

L’authentification multifacteur (MFA) combine des facteurs de natures différentes : quelque chose que vous savez (un mot de passe), quelque chose que vous possédez (un téléphone ou une clé de sécurité) et quelque chose que vous êtes (une empreinte digitale, généralement utilisée seulement pour déverrouiller un appareil). Elle déjoue l’essentiel du bourrage d’identifiants (credential stuffing), où des attaquants essaient des couples nom d’utilisateur et mot de passe divulgués par d’autres sites. Tous les seconds facteurs ne se valent pas : les codes à usage unique envoyés par SMS peuvent être volés par échange de carte SIM (SIM swapping), et aucun code à usage unique, qu’il vienne d’un SMS ou d’une application d’authentification, ne résiste à l’hameçonnage, car l’utilisateur peut être amené par la ruse à le saisir sur un faux site qui le relaie immédiatement. Les lignes directrices du NIST exigent donc que les services au niveau d’assurance de l’authentification 2 proposent au moins une option résistante à l’hameçonnage, et que ceux du niveau 3 en utilisent une.

Une passkey (clé d’accès) est l’option résistante à l’hameçonnage que la plupart des utilisateurs peuvent réellement utiliser. Les passkeys sont des identifiants FIDO2, fondés sur la Web Authentication API du W3C (WebAuthn) et sur le Client to Authenticator Protocol (CTAP) de la FIDO Alliance. À l’enregistrement, l’appareil de l’utilisateur crée une nouvelle paire de clés pour ce site web ; le serveur ne stocke que la clé publique. À la connexion, le serveur envoie un défi aléatoire, et l’appareil le signe avec la clé privée une fois que l’utilisateur l’a déverrouillé par empreinte digitale, reconnaissance faciale ou code PIN. Comme le navigateur lie l’identifiant à l’origine du site web, un site d’hameçonnage qui imite le vrai ne peut pas obtenir de signature valide, et comme le serveur ne détient aucun secret partagé, une violation de sa base de données ne fournit rien qu’un attaquant puisse rejouer. Les passkeys peuvent être liées à un appareil (sur une clé de sécurité matérielle) ou synchronisées entre les appareils d’un utilisateur par une plateforme ou un gestionnaire de mots de passe ; les recommandations 2025 du NIST acceptent les passkeys synchronisées au niveau 2, tandis que le niveau 3 exige une clé non exportable.

Le point faible architectural de tout dispositif d’authentification est la récupération de compte. Si une passkey perdue peut être remplacée en cliquant sur un lien reçu par e-mail, la solidité de tout le système est celle du compte e-mail. Les parcours de récupération méritent leur propre modèle de menaces, des limites de débit, des notifications sur les autres appareils de l’utilisateur et, pour les comptes à forte valeur, des délais ou des vérifications humaines.

Sessions et jetons

Une fois l’utilisateur authentifié, le système doit reconnaître ses requêtes suivantes sans lui redemander qui il est. Il existe deux conceptions de base. Dans une session côté serveur, le serveur stocke la session (utilisateur, expiration, éventuellement rôles) et donne au navigateur un long identifiant de session aléatoire dans un cookie. Dans une conception à jeton autonome, l’émetteur signe un jeton qui porte les revendications (claims), généralement un JSON Web Token (JWT, RFC 7519), et tout service qui détient la clé publique de l’émetteur peut le valider sans rien consulter.

Pour les applications de navigateur, une session côté serveur dans un cookie marqué HttpOnly (invisible pour JavaScript), Secure (HTTPS uniquement) et SameSite est difficile à battre. Les applications monopages utilisent de plus en plus un backend for frontend (BFF) : le navigateur ne détient qu’un cookie de session pour son propre petit backend, qui détient les jetons OAuth et appelle les API pour son compte, une approche que recommandent les lignes directrices du groupe de travail OAuth de l’IETF pour les applications fonctionnant dans le navigateur. Les JWT excellent entre services et dans les applications mobiles, où une vérification sans état à chaque saut évite un goulet d’étranglement central.

import jwt  # PyJWT
from jwt import PyJWKClient

ISSUER = "https://id.fooddelivery.example/"
jwks = PyJWKClient(ISSUER + ".well-known/jwks.json")  # issuer's public keys

def verify_access_token(token: str) -> dict:
    signing_key = jwks.get_signing_key_from_jwt(token)
    return jwt.decode(
        token,
        signing_key.key,
        algorithms=["RS256"],      # pinned: never read from the token header
        audience="orders-api",      # the token must be meant for this API
        issuer=ISSUER,
        options={"require": ["exp", "iat", "sub"]},
    )  # raises an exception on any failure: fail closed

OAuth 2.0 : l’autorisation déléguée

OAuth 2.0 (RFC 6749, 2012) résout un problème précis : permettre à une application d’agir au nom d’un utilisateur sans connaître son mot de passe. Avant OAuth, un service qui voulait importer vos contacts vous demandait le mot de passe de votre messagerie électronique. OAuth définit quatre rôles : le propriétaire de la ressource (l’utilisateur), le client (l’application qui veut obtenir l’accès), le serveur d’autorisation (qui authentifie l’utilisateur, lui demande son consentement et émet les jetons) et le serveur de ressources (l’API qui détient les données). Le client reçoit un jeton d’accès limité par des portées (scopes, comme orders:read), une durée de vie et une audience, et souvent un jeton de rafraîchissement qui permet d’obtenir de nouveaux jetons d’accès sans redemander à l’utilisateur.

OAuth définit plusieurs manières d’obtenir un jeton, appelées octrois (grants). Pour toute application qui agit pour un utilisateur, qu’il s’agisse d’une application web côté serveur, d’une application monopage ou d’une application mobile, l’octroi recommandé est le flux de code d’autorisation avec PKCE (Proof Key for Code Exchange, RFC 7636, 2015). Le client crée d’abord un code_verifier (vérificateur) aléatoire et n’envoie que son hachage SHA-256, le code_challenge (défi), lorsqu’il redirige l’utilisateur vers le serveur d’autorisation. Une fois que l’utilisateur s’est connecté et a donné son consentement, le serveur d’autorisation le redirige vers le client avec un code d’autorisation de courte durée. Le client échange ensuite ce code contre des jetons par une requête directe sur le canal arrière (back channel), en envoyant le vérificateur d’origine ; le serveur vérifie que son hachage correspond au défi. Un attaquant qui intercepte le code, par exemple une application mobile malveillante enregistrée pour la même adresse de redirection, ne peut pas l’échanger sans le vérificateur, qui n’a jamais quitté le client.

L’octroi par identifiants client (client credentials grant) couvre le cas où il n’y a pas d’utilisateur : un service obtient un jeton en son propre nom, par exemple le service d’affectation qui appelle l’API d’un partenaire cartographique, ou le système d’un partenaire qui appelle l’API de statut des commandes de la plateforme. Le client devrait s’authentifier auprès de l’endpoint de jeton avec une clé privée (une assertion JWT signée) ou avec le TLS mutuel (RFC 8705) plutôt qu’avec un secret partagé. Deux octrois plus anciens sont désormais déconseillés : l’octroi implicite, qui renvoyait les jetons dans l’URL du navigateur, et l’octroi par mot de passe du propriétaire de la ressource, qui faisait collecter le mot de passe de l’utilisateur par le client et allait ainsi à l’encontre du but même d’OAuth. La RFC 9700, l’OAuth 2.0 Security Best Current Practice publiée en janvier 2025, consigne ces leçons, notamment la correspondance exacte des adresses de redirection et les jetons liés à l’expéditeur.

OAuth 2.1 regroupe OAuth 2.0 et ces bonnes pratiques en un seul document : PKCE est obligatoire pour le flux de code d’autorisation, les octrois implicite et par mot de passe sont supprimés, les adresses de redirection doivent correspondre exactement et les jetons porteurs (bearer tokens) ne peuvent plus être envoyés dans les chaînes de requête des URL. Au moment où ces lignes sont écrites (octobre 2026), c’est toujours un Internet-Draft de l’IETF (version 16, septembre 2026), et non une RFC, mais ses règles décrivent déjà ce que font les serveurs d’autorisation bien gérés.

OpenID Connect, authentification unique et SAML

OAuth émet des jetons d’accès pour les API ; il n’indique pas, à lui seul, au client qui est l’utilisateur. Utiliser un jeton d’accès comme preuve de connexion est une erreur bien connue, car un jeton émis pour une application peut être rejoué auprès d’une autre qui ne vérifie pas son audience. OpenID Connect (OIDC, Core 1.0, 2014) ajoute la couche d’identité manquante. Avec la portée openid, le serveur d’autorisation, qui joue alors le rôle de fournisseur OpenID, renvoie aussi un jeton d’identité (ID token) : un JWT signé destiné au client, qui indique l’émetteur, l’identifiant stable de l’utilisateur (sub), l’audience (l’identifiant du client), les dates d’émission et d’expiration, un nonce qui le rattache à cette connexion et, facultativement, comment et quand l’utilisateur s’est authentifié. OIDC normalise aussi un endpoint d’informations sur l’utilisateur et des documents de découverte qui publient les endpoints et les clés de signature du fournisseur. La règle empirique : le jeton d’identité est destiné au client, pour savoir qui s’est connecté ; le jeton d’accès est destiné à l’API, pour autoriser les appels.

L’authentification unique (SSO) en découle naturellement : dès qu’un utilisateur a une session auprès du fournisseur d’identité, chaque application qui lui fait confiance peut le connecter sans lui redemander de mot de passe, et la désactivation du compte en un seul endroit coupe l’accès partout. En entreprise, le SSO utilise encore souvent SAML 2.0 (une norme OASIS de 2005), qui échange des assertions XML signées par l’intermédiaire du navigateur. La plateforme de livraison de repas pourrait utiliser OIDC pour ses propres applications et accepter SAML de la part de grandes chaînes de restaurants qui veulent que leur personnel se connecte au portail des restaurants avec ses comptes d’entreprise. Le provisionnement et le déprovisionnement des comptes entre systèmes sont généralement automatisés avec SCIM (RFC 7643 et 7644).

Modèles d’autorisation : RBAC, ABAC et relations

L’authentification indique au système qui appelle ; un modèle d’autorisation décide de ce que l’appelant peut faire. Trois modèles dominent, et les systèmes réels les combinent généralement.

Le contrôle d’accès basé sur les relations est surtout connu par l’article de Google de 2019 sur Zanzibar, le système d’autorisation mondial qui sous-tend Google Drive, Calendar, YouTube et bien d’autres produits. Zanzibar stocke des tuples de relation de la forme object#relation@user, évalue les permissions en les suivant, et utilise des jetons de cohérence pour qu’une vérification de permission ne soit jamais évaluée sur des données plus anciennes que le contenu qu’elle protège ; c’est ce qu’on appelle le problème du « nouvel ennemi » (new enemy problem) : retirer quelqu’un d’un document puis y ajouter un contenu sensible ne doit pas lui permettre de le voir. Parmi les systèmes open source qui s’en inspirent figurent SpiceDB, OpenFGA et Ory Keto.

Quel que soit le modèle, il est utile de séparer le point de décision de politique (PDP), qui évalue la politique et répond « autoriser » ou « refuser », du point d’application de politique (PEP), le code de la passerelle ou du service qui pose la question et applique la réponse. Les moteurs de politiques généralistes comme Open Policy Agent (OPA, projet diplômé de la Cloud Native Computing Foundation, dont les politiques s’écrivent dans son langage Rego) et Cedar (publié en open source par Amazon Web Services en 2023) permettent aux politiques de vivre dans des fichiers versionnés, d’être testées comme du code et d’être évaluées dans le processus ou dans un sidecar, au plus près du service. Sur la plateforme, un découpage en couches raisonnable est le suivant : l’API gateway rejette les requêtes sans jeton valide ou sans la bonne portée (contrôle grossier), et chaque service tranche les questions au niveau de l’objet avec des données que lui seul possède (contrôle fin). La faille Broken Object Level Authorization (autorisation défaillante au niveau de l’objet) est le premier risque de l’OWASP API Security Top 10 (édition 2023), précisément parce que le contrôle fin est celui que les équipes oublient.

Identité de charge de travail : quand l’appelant est un service

Les services s’authentifient les uns auprès des autres bien plus souvent que les personnes ne se connectent, et pourtant les identifiants des services sont souvent les plus faibles : une clé d’API de longue durée dans une variable d’environnement, partagée par plusieurs services et jamais renouvelée. Si cette clé fuit par un journal, un dépôt ou une image de conteneur, l’attaquant devient le service. L’identité de charge de travail (workload identity) remplace ces secrets par des identités que la plateforme émet pour la charge de travail en cours d’exécution, après avoir vérifié ce qu’est cette charge de travail.

Le standard ouvert est SPIFFE (Secure Production Identity Framework for Everyone), un projet diplômé de la Cloud Native Computing Foundation. Il nomme chaque charge de travail par une URI comme spiffe://fooddelivery.example/ns/prod/sa/orders et émet un document de courte durée, renouvelé automatiquement, qui prouve cette identité ; ce document, appelé SVID, est généralement un certificat X.509 (ou un JWT). Son implémentation de référence, SPIRE, atteste le nœud et la charge de travail (par exemple son espace de noms et son compte de service Kubernetes) avant d’émettre l’identité. Les services utilisent ensuite les certificats pour le TLS mutuel, si bien que le service des paiements sait que l’appelant est réellement le service des commandes, et peut autoriser en fonction de l’identité. Les plateformes cloud proposent des équivalents (rôles pour les charges de travail, identités managées, fédération d’identité de charge de travail), et les systèmes de CI comme GitHub Actions peuvent échanger un jeton OIDC signé contre des identifiants cloud de courte durée, si bien que les pipelines n’ont besoin d’aucune clé stockée. La façon dont ces identités servent à construire un réseau sans confiance implicite est le sujet du zero trust.