Autorisation
Sécurité
Processus par lequel un système décide si une entité dont l'identité est déjà établie peut effectuer une action donnée sur une ressource donnée. L'autorisation répond à « qu'a-t-il le droit de faire ? » et vient après l'authentification, jamais à sa place.
Modèles : On attribue les droits par rôles (RBAC), par attributs du sujet, de la ressource et du contexte (ABAC) ou par relations entre objets (ReBAC, « membre de l'équipe propriétaire du dossier »). Les systèmes réels mélangent souvent les trois, avec plus ou moins de bonheur.
Moindre privilège : On refuse par défaut et on n'accorde que le strict nécessaire, pour une durée bornée quand c'est possible. En pratique, le compte de service « temporairement admin » fête souvent ses cinq ans sans que personne ne se souvienne pourquoi.
Décider et appliquer : Le contrôle se fait côté serveur, à chaque requête et sur chaque objet : masquer un bouton dans l'interface n'interdit rien. Oublier de vérifier que l'objet demandé appartient bien au demandeur suffit à ouvrir les données des autres, et ce contrôle d'accès défaillant figure en tête des vulnérabilités web les plus répandues.
Délégation : Avec OAuth 2.0, un jeton d'accès porte des portées (scopes) qui limitent ce qu'une application tierce peut faire au nom de l'utilisateur. Ce jeton transporte des droits, pas une preuve d'identité : c'est le rôle d'OpenID Connect.
Ce qui arrive si on s'en passe
Sans autorisation, toute entité authentifiée reçoit de fait l'ensemble des droits que le système expose. Un compte ordinaire peut alors lire, modifier ou supprimer des ressources appartenant à d'autres, ou lancer des fonctions d'administration dès qu'il en connaît l'adresse ou l'identifiant. L'authentification reste la seule barrière : un seul identifiant compromis, même celui d'un compte aux besoins minimes, ouvre donc tout le périmètre. Le principe du moindre privilège ne peut plus s'appliquer et la séparation des rôles disparaît. Comme aucune décision de refus n'est produite, les journaux ne peuvent pas signaler une tentative d'accès hors du rôle attendu, car rien ne distingue une action légitime d'un abus. Il devient aussi impossible d'établir ce qu'un compte avait réellement le droit de faire, ce qui complique l'analyse d'un abus et la limitation de sa portée.
Explication de la marmotte
Au concert, le billet montré à l'entrée prouve qu'on est bien la personne qui l'a acheté. Mais il n'ouvre pas toutes les portes : avec un billet ordinaire, on reste dans la fosse ; pour aller dans les coulisses, il faut un bracelet spécial. Sur une application, c'est pareil. Une fois connecté, le site vérifie à chaque action ce qu'on a le droit de faire : lire un document, le modifier, le supprimer. Sur l'espace en ligne d'un lycée, un élève peut consulter ses notes, mais seul le professeur peut les changer. Le site décide, porte par porte, qui peut entrer où.
Où ce terme est utilisé
- Requête d'autorisation poussée et signée (PAR, JAR) (32 occurrences)
- Flux par code d'appareil : l'autorisation sur la télévision, et son hameçonnage (19 occurrences)
- Pièges OAuth 2.1 : PKCE, redirections et scopes (19 occurrences)
- FAPI 2.0 : ce qu'un profil de sécurité interdit, et pourquoi (18 occurrences)
- OWASP API Security Top 10 2023 : l'autorisation à trois granularités (15 occurrences)
- DPoP : attacher un jeton d'accès à une clé que le porteur doit prouver détenir (14 occurrences)
- CWE-862 : autorisation manquante, le contrôle qui n'a jamais été écrit (13 occurrences)
- CWE-863 : autorisation incorrecte, le contrôle qui vérifie la mauvaise chose (13 occurrences)
- Jetons d'accès liés au certificat client : ce que mTLS ajoute à OAuth (13 occurrences)
- Attaque par confusion de scope OAuth (12 occurrences)