L’authentification et l’autorisation sont des concepts fondamentaux de la gestion des identités et des accès (IAM), souvent confondus l’un avec l’autre. Bien qu’ils soient tous deux liés à la sécurité des identités, ils ne sont pas interchangeables.

• L’authentification permet de vérifier l’identité d’un utilisateur.
• L’autorisation détermine ce que l’utilisateur peut faire.

À titre d’exemple, imaginez que vous vous connectiez à GitHub (authentification), puis que vous tentiez de supprimer le référentiel d’une autre personne. GitHub sait qui vous êtes, mais vous empêche de réaliser l’action (autorisation).

L’authentification doit intervenir en premier lieu : vous prouvez votre identité. L’autorisation vient ensuite : vos autorisations déterminent ce à quoi vous pouvez accéder.

L’authentification répond à la question « qui êtes-vous ? ».

Avant que votre application ne laisse quelqu’un interagir avec elle, elle doit vérifier son identité. Lorsque des utilisateurs se connectent, vous validez des identifiants (ou d’autres facteurs) pour vérifier qu’ils sont bien ceux qu‘ils prétendent être. L’authentification intervient toujours en premier lieu. Vous ne pouvez pas décider de l’accès d’une personne tant que vous ne savez pas qui elle est.

On peut comparer l’authentification à la sécurité dans les aéroports. Vous présentez votre pièce d’identité pour prouver votre identité, et l’agent vérifie que vous êtes bien la personne que votre pièce d’identité représente.

Méthodes d’authentification courantes

• Authentification par mot de passe : les utilisateurs fournissent des identifiants validés par rapport à des enregistrements stockés. Les mots de passe seuls sont de moins en moins adaptés aux exigences modernes en matière de sécurité.
• Passkeys : les utilisateurs s’authentifient avec des clés cryptographiques protégées localement par la biométrie ou les codes PIN des terminaux. Les passkeys sont des identifiants FIDO résistants au phishing, offrant une connexion plus rapide, plus facile et plus sûre que les mots de passe traditionnels.
• Authentification sociale et identité fédérée : les utilisateurs s’authentifient par l’intermédiaire de fournisseurs externes de confiance (comme Google ou GitHub) à l’aide d’OpenID Connect (OIDC). Ce mécanisme permet de déléguer la vérification de l’identité à des fournisseurs d’identité (IdP) spécialisés.
• Authentification unique (SSO) : les utilisateurs s’authentifient une fois pour accéder à plusieurs applications sans avoir à saisir à nouveau leurs identifiants. Cette méthode permet d’améliorer l’expérience utilisateur, en particulier dans les environnements d’entreprise.
• Authentification multifacteur (MFA) : combine plusieurs facteurs de vérification (par exemple connaissance, possession et inhérence) pour renforcer la sécurité.

Lorsqu’un utilisateur demande l’accès à une application :

1. L’utilisateur soumet des identifiants à l’endpoint d’authentification.
2. Le système valide les identifiants, soit localement, soit via un fournisseur d’identité (IdP).
3. En cas de validation réussie, le système émet des tokens représentant l’identité authentifiée.

L’autorisation répond à la question « que pouvez-vous faire ? ».

L’autorisation détermine ce que les utilisateurs authentifiés ont le droit de faire dans un système. Voici quelques approches courantes :

Méthode	Description	Exemple
Contrôle d'accès basé sur les rôles (RBAC)	Les utilisateurs se voient attribuer des rôles prédéfinis (administrateur, éditeur, lecteur) avec des autorisations fixes.	Un éditeur peut modifier les documents ; un lecteur ne peut que les lire.
Contrôle d’accès basé sur les attributs (ABAC)	Les décisions d’accès sont basées sur des attributs dynamiques (propriétés utilisateurs, métadonnées des ressources, contexte environnemental).	Les ressources financières ne sont accessibles qu’à partir du réseau d’entreprise et pendant les heures de bureau.
Contrôle d’accès basé sur les relations (ReBAC)	L’autorisation est basée sur les relations entre les utilisateurs et les ressources.	Un collaborateur peut modifier ses propres documents, mais pas les brouillons privés de ses collègues.

L’autorisation en pratique

Prenons l’exemple d’une application de gestion de projet :

• L’authentification confirme que l’utilisateur est Alex.
• L’autorisation détermine qu’Alex (dans un rôle de chef de projet) peut voir tous les projets de l’équipe de développement, mais ne peut pas supprimer les projets ni accéder aux paramètres de facturation.

Lorsque vous travaillez avec des protocoles modernes, il est essentiel de comprendre les distinctions entre l’authentification et l’autorisation.

Aspect	Authentification	Autorisation
Question	Qui êtes-vous ?	Que pouvez-vous faire ?
Processus	Vérifie l’identité	Vérification des autorisations
Séquence	Doit intervenir en premier lieu	Intervient après l’authentification
Méthodes	Mots de passe, passkeys, MFA, SSO, OIDC	RBAC, ABAC, ReBAC
Type de token	Token d’identification (revendications d’identité)	Token d’accès (autorisations/champs d’application)
État HTTP	401 Unauthorized (impossible de prouver l’identité)	403 Forbidden (identité connue, autorisation refusée)

OAuth 2.0 est un framework d’autorisation, pas un protocole d’authentification.

OAuth 2.0 offre un moyen standardisé pour une application client d’obtenir un token d’accès auprès d’un serveur d’autorisation (avec le consentement d’un utilisateur) afin d’accéder à des ressources protégées. Il a été conçu pour l’autorisation déléguée, permettant à des utilisateurs d’accorder à des applications tierces un accès limité à leurs ressources sans partager leurs mots de passe.

C’est là qu’OpenID Connect (OIDC) entre en scène

OIDC est un protocole d’authentification interopérable basé sur OAuth 2.0. Il simplifie le processus de vérification de l’identité des utilisateurs sur la base de l’authentification effectuée par le serveur d’autorisation.

Il offre des possibilités que ne permet pas OAuth 2.0 :

• Il définit le token d’identification : un token de sécurité standardisé (encodé comme un JWT) qui sert de preuve que l’utilisateur a été authentifié.
• Il standardise les revendications d’identité de l’utilisateur (comme le nom et l’adresse e-mail).

Dans les architectures modernes :

• OAuth 2.0 gère l’autorisation (délégation de l’accès aux ressources).
• OpenID Connect gère l’authentification (confirmation de l’identité de l’utilisateur).

Les deux protocoles travaillent généralement ensemble dans le même flux.

Les applications modernes sont des systèmes distribués construits autour d’API et sont devenues un moyen d’accès essentiel aux ressources.

Le changement fondamental : les API n’authentifient pas directement les utilisateurs. Elles valident des tokens et appliquent les autorisations d’accès aux API.

Fonctionnement de l’authentification par token

1. L’utilisateur s’authentifie auprès d’un serveur d’autorisation (fournisseur d’identité).
2. Le serveur émet des tokens après avoir validé l’identité :
   • Token d’identification (authentification) : informations sur l’identité de l’utilisateur. Le client s’en sert pour déterminer qui s’est connecté.
   • Token d’accès (autorisation) : informations d’autorisation (champs d’application, autorisations d’accès). L’API s’en sert pour déterminer ce à quoi l’utilisateur peut accéder.
3. Le client effectue des appels d’API avec le token d’accès dans l’en-tête [Authorization: Bearer].
4. L’API valide le token et applique les règles d’autorisation en fonction des revendications qu’il contient.

Comprendre l’authentification par JWT

Les JWT (JSON Web Tokens) constituent le format de tokens le plus courant. Ils sont autonomes et contiennent toutes les informations nécessaires embarquées dans le token lui-même.

Un JWT se compose d’un en-tête, d’une charge utile (revendications) et d’une signature.

Validation des JWT : ce que l’API doit vérifier

Lorsqu’une API reçoit un JWT, la validation n’est pas négociable. Ignorer l’une ou l’autre de ces validations crée des vulnérabilités au niveau de la sécurité des applications.

Cinq contrôles de validation essentiels :

1. Structure du token : vérifiez tout d’abord que le token correspond à la structure d’un JWT.
2. Intégrité du token : vérifiez que le token n’a pas été altéré en inspectant la signature.
3. Expiration du token : vérifiez si le token a expiré, comme défini par la revendication exp.
4. Autorité attendue : vérifiez que le token a été émis et signé par l’expéditeur attendu.
   1. Comparez-la à la revendication iss (émetteur).
   2. Vérifiez que la clé utilisée pour signer le JWT appartient à l’autorité attendue.
5. Profils cibles attendus : vérifiez que le token est destiné à votre application et que la revendication aud correspond à la valeur identifiant votre application.

JWT ou tokens opaques : les compromis

OAuth 2.0 n’impose pas de format de tokens d’accès spécifique. Bien que les JWT soient populaires, les tokens opaques constituent une alternative. Un token opaque est une chaîne aléatoire qui ne contient aucune information embarquée sur l’utilisateur ou le token lui-même.

Fonctionnalités	Tokens d’accès JWT	Tokens d’accès opaques
Validation	Sans état (l’API valide localement)	Avec état (l’API doit appeler l‘endpoint d’introspection du serveur d’autorisation à chaque requête)
Révocation	Difficile à révoquer avant l’expiration	Capacité de révocation instantanée
Performances	Diminution de la latence des requêtes d’API (plus rapides)	Latence accrue par la recherche du serveur d’autorisation
Évolutivité	Bonne évolutivité dans les architectures distribuées	Le serveur d’autorisation devient une dépendance critique

Les deux sont des implémentations OAuth 2.0 valides. De nombreux systèmes utilisent des JWT avec des délais d’expiration courts et une rotation des tokens d’actualisation afin d’équilibrer les performances et la sécurité.

Le flux de type code d’autorisation avec PKCE (Proof Key for Code Exchange) est le flux OAuth 2.0 le plus sûr pour les applications web et mobiles, démontrant comment l’authentification et l’autorisation fonctionnent ensemble. L’utilisation de PKCE protège le flux contre les attaques par interception.

1. L’utilisateur initie la connexion : l’application redirige l’utilisateur vers le serveur d’autorisation avec les détails de la requête (ID client, champs d’application, demande de code PKCE).
2. L’utilisateur s’authentifie : l’utilisateur se connecte via la page de connexion hébergée. L’authentification est terminée.
3. Code d’autorisation émis : l’utilisateur est redirigé vers l’application avec un code d’autorisation de courte durée.
4. Échange de tokens : le backend de l’application échange le code d’autorisation contre des tokens, en envoyant le vérificateur de code PKCE. Le serveur émet le token d’identification (authentification) et le token d’accès (autorisation).
5. Accès aux API : l’application inclut le token d’accès dans les en-têtes des requêtes lorsqu’elle appelle des API protégées.
6. Validation du token et application du niveau d’accès défini : l’API valide le token d’accès et applique le niveau d’accès sur la base de ses revendications, garantissant ainsi une autorisation correcte.

Considérations de sécurité pour les développeurs

Considération	Recommandation
Durée de vie des tokens	Utilisez des tokens d’accès de courte durée (15 à 60 minutes) et un token d’actualisation pour obtenir de nouveaux tokens d’accès sans obliger les utilisateurs à se connecter.
Principe du moindre privilège	Demandez les champs d’application minimaux requis dont une application a besoin pour réduire les risques de dommages potentiels issus de tokens compromis.
Validation des tokens	Validez toujours les tokens pour réduire les risques de sécurité.
Stockage des tokens	Ne stockez jamais de tokens sensibles dans localStorage ou sessionStorage. Utilisez des cookies HttpOnly sécurisés ou le stockage de session backend.

Pour créer des applications sécurisées, il faut comprendre la distinction entre l’authentification et l’autorisation :

Concept	Objectif	Protocole / Token
Authentification	Vérification de l’identité	OpenID Connect, token d’identification
Autorisation	Contrôle des accès	OAuth 2.0, token d’accès

Checklist pour l’implémentation

• Utiliser OpenID Connect pour l’authentification des utilisateurs
• Utiliser OAuth 2.0 pour l’autorisation déléguée
• Valider les JWT côté serveur à chaque requête d’API
• Renvoyer 401 en cas d’échec de l’authentification, 403 en cas de refus d’autorisation
• Utiliser le flux de type code d’autorisation avec PKCE
• Stocker les tokens en toute sécurité (cookies HttpOnly)
• Utiliser des tokens d’accès de courte durée avec rotation des tokens d’actualisation

Pour en savoir plus sur les différents types de tokens, découvrez la différence entre le token d’identification et le token d’accès.

L’utilisation d’un service comme Auth0 peut simplifier l’implémentation de l’authentification et de l’autorisation, permettant aux développeurs de se concentrer sur la logique de leur application principale. Explorez notre série d’articles « Introduction à l’IAM » pour en savoir plus sur la gestion des identités et des accès.

En savoir plus

Le contenu de ce document revêt un caractère purement informatif. Il vous revient de vous adresser à des conseillers professionnels pour obtenir des conseils en matière de sécurité, confidentialité, conformité ou conduite des affaires, et de ne pas vous en remettre aux recommandations formulées dans le présent document.