L’autorisation détermine ce qu’une identité authentifiée (utilisateur, application ou service) peut faire et les ressources auxquelles elle peut accéder dans un système.

Dans la plupart des systèmes, l’autorisation suit l’authentification. Une fois que le système sait qui vous êtes, l’autorisation détermine ce que vous pouvez faire.

L’autorisation assure que chaque identité authentifiée respecte les limites définies. Sans elle, un utilisateur qui se connecte avec succès (authentification) pourrait accéder à toutes les données sensibles et effectuer n’importe quelle action (autorisation). Dans les architectures Zero Trust, les décisions d’autorisation sont évaluées en permanence tout au long d’une session, et pas seulement lors de l’accès initial.

L’autorisation relie trois composants principaux :

• Utilisateurs (identités authentifiées)
• Autorisations (droits spécifiques pour effectuer des actions, comme read:Patients)
• Ressources (actifs à protéger)

Contrôle d’accès basé sur les rôles (RBAC)

Le contrôle d’accès basé sur les rôles (RBAC, Role-Based Access Control) est le modèle d’autorisation de base. Il simplifie la gestion des autorisations en attribuant des autorisations à des rôles (par exemple administrateur, éditeur, lecteur), puis en attribuant ces rôles à des utilisateurs.

• Comment fonctionne-t-il ? Le système vérifie le ou les rôles attribués à l’utilisateur et regroupe leurs autorisations pour déterminer si l’action demandée est autorisée.
• Quand l’utiliser ? Lorsque les autorisations de l’utilisateur correspondent clairement à des fonctions statiques ou à des groupes (par exemple dans une entreprise type ou une application d’administration).
• Quelles sont ses limites ? Le contrôle RBAC est moins adapté aux politiques dynamiques ou contextuelles, telles que celles basées sur le terminal, l’heure ou le lieu, car les rôles sont généralement statiques.

Les systèmes IAM d’entreprise et les environnements cloud à grande échelle implémentent un contrôle RBAC via leurs frameworks.

Contrôle d’accès basé sur les attributs (ABAC)

Le contrôle d’accès basé sur les attributs (ABAC, Attribute-Based Access Control) utilise des politiques dynamiques qui évaluent les attributs de l’utilisateur, des ressources et de l’environnement pour prendre une décision d’accès.

• Comment fonctionne-t-il ? L’accès est déterminé par des expressions de politique qui évaluent la situation en temps réel (par exemple user.department == resource.department, ou en vérifiant si l’heure actuelle est comprise dans les heures de bureau).
• Quand l’utiliser ? Lorsque les décisions d’autorisation sont complexes, très contextuelles ou dépendantes de facteurs dynamiques (par exemple en n’autorisant l’accès qu’à partir d’une plage IP d’entreprise, en n’autorisant l’accès aux documents que pendant les heures de bureau, ou en exigeant des niveaux d’habilitation de sécurité spécifiques pour les ressources sensibles).
• Quelles sont ses limites ? Il introduit de la complexité. Les politiques doivent être conçues avec soin et testées de manière approfondie afin d’éviter tout conflit ou accès involontaire pour diverses combinaisons d’attributs.

Les moteurs de politiques basés sur des standards (comme Open Policy Agent ou XACML) appliquent des politiques ABAC pour assurer la cohérence et l’auditabilité.

Contrôle d’accès basé sur les relations (ReBAC) et autorisation granulaire (FGA)

Le contrôle d’accès basé sur les relations (ReBAC, Relationship-Based Access Control) fonde l’autorisation sur les relations et la propriété entre un utilisateur et une ressource spécifique.

• Comment fonctionne-t-il ? Le système vérifie les relations explicites (par exemple « propriétaire de », « partagé avec », « membre du groupe ») pour accorder ou refuser l’accès. Les implémentations actuelles utilisent une modélisation des relations basée sur des graphes pour naviguer dans des chaînes d’autorisation complexes.
• Quand l’utiliser ? Dans les systèmes collaboratifs tels que les réseaux sociaux ou les plateformes de partage de documents (par exemple « seul le propriétaire de la publication peut la supprimer », « les utilisateurs des espaces de travail partagés peuvent consulter tous les documents »).

Les systèmes ReBAC et FGA s’appuient sur une infrastructure sensible aux relations et des modèles d’autorisation basés sur des graphes pour modéliser et interroger ces relations à grande échelle. Plusieurs implémentations open source (telles qu’OpenFGA et SpiceDB) rendent cette technologie accessible à tous les développeurs.

L’autorisation granulaire (FGA, Fine-Grained Authorization) étend les principes du contrôle ReBAC pour permettre la prise de décisions d’autorisation fondées sur des graphes relationnels complexes à grande échelle. Les systèmes FGA peuvent répondre à des questions telles que « l’utilisateur X peut-il modifier le document Y ? » en analysant les relations entre les groupes, les organisations et les autorisations imbriquées. Ce modèle gère l’autorisation dans la collaboration documentaire et sur les plateformes de réseaux sociaux, où l’accès peut être hérité via des hiérarchies de dossiers, des appartenances à des groupes et des relations de partage.

Les applications pilotées par API appliquent l’autorisation via des tokens d’accès émis par le flux d’autorisation OAuth 2.0.

1. Mappage des autorisations : après une authentification réussie, le serveur d’autorisation détermine les autorisations accordées à l’utilisateur sur la base du modèle d’autorisation choisi et de toute politique dynamique applicable (par exemple RBAC ou ABAC).
2. Émission de tokens : le serveur émet un token d’accès, le plus souvent un JWT (JSON Web Token) qui contient des revendications sur le sujet et les champs d’application autorisés. Il peut aussi émettre un token opaque qui doit être validé par l’endpoint d’introspection du serveur d’autorisation. Le flux d’authentification détermine la manière dont les tokens sont acquis et les revendications qu’ils contiennent.
3. Implémentation d’API : lorsqu’une API reçoit une requête, elle valide le JWT et applique les règles d’autorisation sur la base des revendications contenues dans le token.

Cette approche par token est sans état. Le token contient tout ce dont l’API a besoin : un contexte d’autorisation et une signature cryptographique.

Les champs d’application définissent les autorisations qu’une application client demande au serveur d’autorisation. Le serveur d’autorisation n’accorde que les champs d’application pour lesquels l’utilisateur a donné son consentement et les inclut dans le token d’accès émis.

• Lorsqu’une application demande un token d’accès, elle spécifie les champs d’application dont elle a besoin (par exemple read:documents, write:documents).
• Le serveur d’autorisation compare les champs d’application demandés aux autorisations réelles de l’utilisateur et n’accorde que ce que l’utilisateur peut autoriser.
• Le token d’accès émis contient les champs d’application approuvés. L’API vérifie que le token contient les champs d’application requis pour l’opération demandée. Dans le cas contraire, l’API refuse l’accès.

Les rôles définissent généralement de vastes ensembles d’accès, tandis que les champs d’application représentent des autorisations granulaires au niveau des actions. La combinaison des rôles et des champs d’application offre une souplesse accrue pour les API.

OpenID Connect (OIDC) étend OAuth 2.0 en permettant l’émission de tokens d’identification pour la vérification de l’identité des utilisateurs et les revendications de profil, en plus des champs d’application d’autorisation.

Chaque API endpoint protégé doit valider le token d’accès entrant. Vérifiez la signature du token (pour garantir son intégrité et son authenticité), l’expiration (revendication exp), les profils cibles (revendication aud), l’émetteur (revendication iss) et les autorisations requises (champs d’application ou rôles). Une validation supplémentaire peut inclure la vérification de l’état de révocation du token, la validation de la revendication nbf (Not Before) et l’application de la limitation du débit par client. Pour les JWT, les serveurs d’autorisation publient des clés publiques via l’endpoint JSON Web Key Set (JWKS) pour la vérification des signatures.

Les API doivent renvoyer des codes d’état HTTP spécifiques pour communiquer le type d’échec.

• 401 Unauthorized : signifie que l’authentification a échoué ou est absente. La demande ne comporte pas d’identifiants valides (le token est manquant, invalide ou arrivé à expiration).
  Exemples : en-tête Authorization manquant, JWT arrivé à expiration, signature invalide.
• 403 Forbidden : signifie que l’autorisation a échoué. L’identité de l’utilisateur est connue (authentifiée), mais ses autorisations lui refusent l’accès à la ressource ou à l’action demandée.
  Exemples : le token est valide, mais l’utilisateur n’a pas le rôle admin pour l’action DELETE /users/:id, avec pour résultat un champ d’application insuffisant pour l’opération demandée.

Quel risque de sécurité entraîne l’incohérence des contrôles d’autorisation ?

Lorsque la logique d’autorisation est dispersée dans le code, certains chemins peuvent ne pas appliquer les contrôles requis, ce qui laisse des vulnérabilités que les attaquants peuvent exploiter. La bonne pratique consiste à centraliser l’application des autorisations à l’aide d’un middleware ou d’un moteur de politiques. Les approches émergentes comprennent la politique en tant que code (PaC), qui utilise des langages tels que Rego (Open Policy Agent), séparant la logique d’autorisation du code applicatif et permettant la centralisation des tests et des audits.

Qu’est-ce que le principe du moindre privilège ?

Ce principe consiste à n’accorder aux utilisateurs ou aux services que les rôles et autorisations minimaux nécessaires à l’exercice de leurs fonctions, afin de minimiser les dommages potentiels en cas de compromission d’identité. En pratique, cela signifie qu’il faut vérifier régulièrement les autorisations, implémenter des autorisations d’accès limitées dans le temps et supprimer les rôles ou les champs d’application inutilisés.

Quand dois-je utiliser l’authentification renforcée ?

L’authentification renforcée concilie sécurité et convivialité. Elle demande à un utilisateur déjà authentifié de fournir des facteurs supplémentaires (tels qu’une lecture biométrique) uniquement lorsqu’il entreprend une opération à haut risque, comme un virement bancaire ou une modification de la paie. Cette approche est également appelée authentification adaptative ou authentification contextuelle.

Quelle serait une vulnérabilité courante en matière d’autorisation ?

L’une des vulnérabilités courantes est la vulnérabilité Broken Object-Level Authorization (BOLA), également appelée Insecure Direct Object Reference (IDOR). Elle se produit lorsqu’une API vérifie l’autorisation générale (par exemple « peut lire un document »), mais ne vérifie pas si l’utilisateur a accès à l’identifiant de ressource spécifique demandé (par exemple « identifiant de document 12345 »). Cette vulnérabilité est systématiquement classée au premier rang API1:2023 du Top 10 OWASP des risques de sécurité des API. Validez toujours l’autorisation de l’action et l’accès au niveau des ressources.

Quelle est la différence entre l’autorisation et le contrôle des accès ?

L’autorisation est un composant du contrôle des accès. Le contrôle des accès est la discipline de sécurité plus large qui englobe l’authentification (vérification de l’identité), l’autorisation (octroi d’autorisations) et l’application (mise en exécution des politiques). L’autorisation fait explicitement référence à la prise de décisions et à la mise en application de ce qu’une identité authentifiée peut faire.

Comment fonctionne l’autorisation dans les architectures en microservices ?

Les systèmes distribués appliquent l’autorisation à plusieurs niveaux : passerelle API (granularité limitée), maillage de services (niveau du réseau) ou services individuels (granularité fine). L’autorisation par token à l’aide de JWT permet une vérification sans état entre les services. Cependant, il est difficile de maintenir une cohérence. Les mises à jour des politiques doivent atteindre tous les services, et les décisions basées sur les relations nécessitent un moteur de politiques centralisé ou une mise en cache distribuée.

L’autorisation est un composant d’une stratégie complète de gestion des identités et des accès. Les frameworks d’autorisation modernes, tels qu’OAuth 2.0 et OpenID Connect, ainsi que les modèles granulaires comme ABAC, ReBAC et l’autorisation granulaire (FGA), permettent aux développeurs de créer des applications plus sûres et plus évolutives qui respectent les principes Zero Trust. Pour en savoir plus sur l’authentification, les modèles de contrôle des accès et les bonnes pratiques de sécurité, explorez la série d’articles « Introduction à l’IAM » d’Auth0.

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.