Authentification ou autorisation : quelles différences ?

Niveau : débutant à intermédiaire.

Prérequis : connaître les notions de compte, application Web, requête HTTP, rôle et journal. Savoir créer un fichier texte suffit pour l’exercice. Aucun annuaire, fournisseur cloud ou outil offensif n’est requis.

L’exercice porte sur une application fictive et des événements locaux. Il ne demande ni mot de passe réel, ni jeton actif, ni interaction avec un service tiers.

Une identité est une représentation d’un sujet dans un contexte donné. Le sujet peut être une personne, un processus, une machine ou une application. Une même personne peut avoir une identité professionnelle, une identité personnelle et un compte d’administration séparé. À l’inverse, un compte partagé rend difficile l’attribution d’une action à un sujet précis.

Le compte est l’enregistrement géré par un système : il contient un identifiant, un état, des attributs et des relations avec des rôles ou groupes. L’identifiant, comme lea, sert à désigner le compte. Il n’est pas une preuve. Connaître une adresse électronique ne démontre pas que tu contrôles l’identité correspondante.

Le cycle de vie compte autant que la création : rattachement à un responsable, modification après un changement de fonction, désactivation au départ et conservation limitée des traces. Le NIST SP 800-63-4 distingue notamment la preuve d’identité, l’authentification et la fédération. Cette distinction évite de croire qu’un compte techniquement valide représente encore une relation métier actuelle.

L’authentification répond à une question bornée : le sujet qui se présente apporte-t-il une preuve acceptable pour le compte annoncé ? Cette preuve peut être un secret, un dispositif cryptographique ou un mécanisme fourni par un système de confiance. La décision dépend aussi du protocole, de la qualité de l’implémentation, de l’état du compte et parfois du contexte.

Une réussite signifie seulement que la politique d’authentification a accepté les éléments présentés à cet instant. Elle ne prouve pas que la personne est légitime dans chaque situation, que son poste est sain ou que son compte doit accéder à toutes les données. Une preuve peut être volée, une récupération de compte peut être faible et un compte peut rester actif après un départ.

L’authentification multifacteur renforce certains scénarios, mais elle constitue un sujet distinct. Consulte l’article complémentaire sur les méthodes et limites de la MFA pour ce choix précis. Ici, retiens surtout que le résultat d’authentification alimente la suite du contrôle sans remplacer la décision d’autorisation.

Une application Web reçoit des requêtes séparées. Après une authentification réussie, elle crée souvent une session afin d’éviter une nouvelle vérification complète à chaque clic. Le navigateur conserve généralement un identifiant opaque dans un cookie, tandis que le serveur associe cet identifiant à un compte, une heure de création, une expiration et d’autres attributs. Une autre architecture peut utiliser un jeton signé, avec des compromis différents.

La session doit être difficile à deviner, protégée pendant le transport, renouvelée après l’authentification et invalidée lors d’une déconnexion ou d’un événement sensible. Les attributs Secure, HttpOnly et SameSite contribuent à limiter certains usages du cookie sans corriger toutes les faiblesses applicatives. La RFC 6265 décrit le modèle des cookies HTTP.

Une session authentifiée peut expirer, être révoquée ou devenir insuffisante pour une action sensible. L’application peut alors demander une authentification récente. Inversement, fermer un onglet ne détruit pas forcément la session côté serveur. Pour analyser un événement, distingue l’heure d’authentification, l’identifiant de session, la dernière activité, l’expiration et la révocation effective.

L’autorisation répond à une autre question : ce sujet peut-il réaliser cette action sur cette ressource dans ce contexte ? Une politique peut considérer un rôle, un groupe, la propriété d’un objet, sa classification, l’heure, l’état d’un appareil ou une approbation. La décision doit être appliquée côté serveur à chaque opération protégée, même si l’interface masque déjà le bouton.

Dans une bibliothèque fictive, lea peut lire son propre dossier sans pouvoir modifier celui de sam. Le rôle bibliothecaire peut enregistrer un retour, tandis que le rôle responsable peut modifier les règles de prêt. Le fait que lea soit authentifiée ne répond à aucune de ces décisions. Il faut connaître la ressource et l’action.

L’OWASP Authorization Cheat Sheet recommande notamment le refus par défaut, le moindre privilège, une validation sur chaque requête et des tests unitaires ou d’intégration. Une réponse 403 Forbidden indique généralement que la requête est comprise mais refusée. Un 401 Unauthorized signale plutôt l’absence ou l’invalidité des éléments d’authentification HTTP, malgré un nom historique trompeur.

Avec la fédération, une application s’appuie sur un fournisseur d’identité. Le fournisseur authentifie le sujet et transmet une assertion ou un jeton selon un protocole défini. L’application reste responsable de la validation des données reçues et de ses propres autorisations. Un groupe transmis par l’annuaire peut contribuer à la décision, mais il ne dispense pas de contrôler la ressource demandée.

La délégation permet à une application d’obtenir un accès limité à une autre ressource au nom d’un sujet ou pour son propre compte. Dans OAuth 2.0, les rôles de propriétaire de ressource, client, serveur d’autorisation et serveur de ressources sont distincts. La RFC 6749 décrit ce cadre d’autorisation. OAuth n’est pas, à lui seul, une preuve universelle d’identité.

Un écran de consentement ne garantit pas non plus que le périmètre demandé est raisonnable. Vérifie l’audience, les portées, la durée et le serveur destinataire. Un jeton accepté par la mauvaise ressource ou sans validation de son audience peut élargir l’accès. Le bon schéma note donc qui authentifie, qui émet, qui reçoit, quelle action est permise et pendant combien de temps.

Pour analyser un accès, déroule les étapes dans l’ordre :

1. Sujet annoncé : quel compte ou service se présente ?
2. Preuve : quel mécanisme vérifie ce rattachement, à quel instant et avec quel résultat ?
3. Session : quel identifiant maintient l’état, quelle durée s’applique et comment intervient la révocation ?
4. Demande : quelle action vise quelle ressource ?
5. Politique : quelles règles et quels attributs sont évalués ?
6. Décision : accès accordé, refusé ou soumis à une condition supplémentaire ?
7. Trace : quelles données permettent de relier décision, politique, session et ressource ?

Exemple local : un utilisateur ouvre /factures/42. Le serveur associe le cookie à user_id=17, puis vérifie que la facture 42 appartient au client lié à ce compte. Changer l’URL vers /factures/43 ne doit jamais suffire à obtenir une autre facture. Le contrôle décisif est l’autorisation sur l’objet 43, pas la présence d’une session valide.

Dans les journaux, conserve des identifiants techniques adaptés sans inscrire de secret. Une trace utile indique la décision, le compte, la ressource, l’action, la règle ou version de politique et un identifiant de corrélation. Elle ne doit pas contenir le mot de passe, le cookie complet ou le jeton actif.

Crée un fichier acces-identite.txt et colle ces événements fictifs :

E1 account=lea event=account_created owner=atelier-boreal
E2 account=lea event=authentication result=success session=s-17
E3 session=s-17 action=read resource=invoice-42 decision=allow reason=owner
E4 session=s-17 action=read resource=invoice-43 decision=deny reason=not_owner
E5 session=s-17 event=session_revoked reason=user_logout
E6 session=s-17 action=read resource=invoice-42 decision=deny reason=invalid_session

Travaille uniquement dans un éditeur local. Ne transforme pas ces identifiants en requêtes vers un site. Crée un tableau avec les colonnes événement, couche, fait observable et conclusion interdite. Classe E1 comme cycle de vie de l’identité, E2 comme authentification et création de session, E3 et E4 comme autorisation, E5 comme révocation de session, puis E6 comme refus lié à la session invalide.

Explique ensuite pourquoi E2 ne permet pas de prévoir la décision de E4, et pourquoi E4 ne démontre pas un échec d’authentification. Note que les lignes ne révèlent ni la méthode d’authentification, ni la qualité de la preuve, ni l’identité humaine derrière le compte.

Critère observable

Ton tableau contient exactement six lignes classées, sans placer E3 ou E4 dans la catégorie authentification. Il mentionne que la session s-17 est acceptée avant E5 puis refusée après révocation, et formule au moins trois limites liées aux données absentes.

• Appeler toute décision une authentification. Un 403 peut suivre une authentification parfaitement réussie.
• Considérer le nom du compte comme une preuve. Un identifiant sert à désigner, pas à démontrer le contrôle.
• Faire confiance à l’interface. Masquer un bouton ne remplace jamais le contrôle côté serveur.
• Autoriser uniquement à l’ouverture de session. Les droits, la ressource ou le contexte peuvent changer pendant la session.
• Confondre jeton et permission absolue. Vérifie signature, émetteur, audience, expiration et portée selon le protocole.
• Oublier les identités de service. Un processus doit lui aussi être authentifié et limité.
• Journaliser des secrets. Un cookie ou jeton complet dans un journal crée un nouveau risque.
• Prendre une réussite pour une attribution humaine certaine. Une preuve acceptée peut avoir été partagée ou compromise.

Ces quatre couches ne sont pas toujours implémentées par quatre composants. Un fournisseur peut gérer compte, authentification et session, tandis que l’application garde l’autorisation métier. Les frontières varient, mais les questions restent distinctes. Documente le propriétaire de chaque décision, le comportement en cas d’indisponibilité, la durée des sessions, les moyens de révocation et les preuves attendues.

Aucune architecture d’identité ne supprime les erreurs logiques, les comptes obsolètes ou les abus internes. Les tests doivent couvrir les accès permis et refusés, entre utilisateurs, rôles et états de session. Une revue régulière vérifie ensuite que la politique décrite correspond encore aux droits effectifs.