Comment concevoir des permissions déléguées dans une application PHP

Permettre à une personne de gérer des tâches au nom d’une autre peut répondre à un véritable besoin métier, mais cela ne devrait pas impliquer le partage de mots de passe ni l’octroi d’un accès général au compte. Dans une application PHP, une délégation sécurisée doit préciser qui agit, qui cette personne représente, sur quelles ressources elle peut intervenir et pendant combien de temps. Elle doit également pouvoir être révoquée et faire l’objet d’un audit.

L’objectif est d’autoriser une action précise tout en conservant l’identité des deux personnes. Cela exige davantage qu’un écran permettant d’accorder des permissions : cela concerne le modèle de données, chaque point d’autorisation, les opérations asynchrones et les tests. Concevoir ces éléments ensemble réduit le risque qu’une délégation valide dans un écran se transforme, via un autre chemin, en accès excessif.

Distinguer délégation, usurpation d’identité et accès partagé

Dans le cadre d’une délégation, la personne qui lance l’opération reste l’identité authentifiée. L’application consigne également qu’elle agit au nom d’une autre personne, dans le cadre d’une autorisation limitée. La personne représentée ne s’est pas connectée et ne doit pas apparaître comme l’auteure directe de la requête.

L’usurpation d’identité modifie l’identité effective sous laquelle le système traite une requête et peut masquer l’auteur de l’action si elle n’est pas mise en œuvre avec des contrôles spécifiques. L’accès partagé, par exemple lorsqu’on communique des identifiants, supprime la séparation entre les utilisateurs et complique la révocation ou l’attribution des activités. Pour un flux de délégation ordinaire, aucune de ces approches ne remplace un contexte explicite distinguant l’acteur du principal représenté.

Il est préférable de nommer ces deux rôles dans le code et dans les journaux. Par exemple, actor_id identifie la personne qui a exécuté l’opération et principal_id, la personne au nom de laquelle elle a été réalisée. Évitez les noms ambigus comme user_id dans les journaux, car ils pourraient désigner l’une ou l’autre.

Définir le périmètre, les ressources et la durée avant l’implémentation

Une délégation utile décrit précisément ce qu’elle autorise. « Gérer le compte » est généralement trop large. On peut plutôt la limiter à des actions telles que consulter des tâches, mettre à jour leur état ou répondre à une demande. Si les actions ont des conséquences différentes, modélisez des permissions distinctes au lieu de regrouper lecture, modification, approbation et suppression sous une capacité générique.

Définissez également le périmètre des ressources : une organisation, un projet, une boîte de réception de tâches ou un ensemble précis d’enregistrements. La permission de modifier les tâches d’un projet ne devrait pas autoriser la lecture des données d’un autre projet au seul motif que le même utilisateur délégué peut y accéder dans le cadre d’une autre fonctionnalité.

La durée doit avoir un début et une fin clairement définis, ainsi qu’un état permettant de révoquer la délégation avant son expiration. Décidez quel fuseau horaire utiliser pour afficher les dates et veillez à la cohérence des comparaisons internes. Si la politique exige une approbation ou interdit les délégations en chaîne, formalisez cette exigence en une règle explicite et vérifiable ; ne la laissez pas au stade de convention d’interface.

Modéliser l’autorisation et la vérifier pour chaque opération

Un schéma relationnel peut représenter une délégation avec des champs tels qu’un identifiant, l’acteur autorisé, le principal représenté, le périmètre, les actions, les dates de début et d’expiration, l’état, le créateur et la date de révocation. La structure exacte dépend du domaine : les actions peuvent être enregistrées dans une table associée ou dans un autre format validé, mais elles doivent pouvoir être consultées et vérifiées sans interprétation ambiguë.

L’autorisation doit distinguer l’autorité du principal de l’autorisation déléguée à l’acteur. Pour l’opération demandée, vérifiez que le principal représenté aurait un accès ordinaire à la ressource et que les règles métier applicables l’autorisent. Vérifiez ensuite que l’acteur authentifié est bien le destinataire d’une délégation en vigueur et non révoquée, et que celle-ci autorise cette action sur cette ressource. La permission effective est limitée par l’accès du principal et par le périmètre de la délégation : celle-ci ne peut accorder à l’acteur ni davantage d’actions ou de ressources que le principal n’est autorisé à déléguer, ni davantage que ce qui figure dans la délégation elle-même. N’exigez pas que l’acteur dispose également d’un accès propre à la ressource : il peut précisément agir grâce à la délégation. Appliquez toutefois les restrictions liées à l’identité de l’acteur, telles que l’authentification, l’appartenance au contexte requis ou les contrôles de sécurité de l’opération.

En pratique, la vérification devrait inclure les points suivants :

• L’acteur est authentifié et la délégation lui est bien destinée.
• Le principal représenté est valide dans ce contexte et dispose d’un accès ordinaire à la ressource demandée.
• La délégation est active au moment de l’opération, n’a pas été révoquée et se trouve dans sa période de validité.
• L’action demandée et la ressource entrent dans le périmètre accordé, sans dépasser l’autorité du principal.
• Les règles métier et les contrôles de sécurité applicables à l’acteur et à l’opération sont respectés.

Centralisez cette décision dans un service d’autorisation ou une politique réutilisable, plutôt que de répéter des conditions partielles dans les contrôleurs. Invoquez néanmoins cette vérification pour chaque opération concernée : une vue protégée ne protège pas automatiquement une API, un téléchargement, une action groupée ou une route d’administration. En PHP, le contrôleur peut récupérer l’acteur authentifié, résoudre le contexte de délégation et demander au service d’autoriser l’action sur la ressource concernée. La couche métier peut également imposer des invariants essentiels lorsqu’une opération a des conséquences importantes.

Ne faites pas confiance à un principal_id envoyé par le navigateur comme preuve d’autorisation. Le serveur doit vérifier la relation entre l’acteur, le principal, la délégation, la ressource et l’action à partir de données fiables. Ne partez pas non plus du principe que masquer un bouton dans l’interface empêche l’appel direct du point de terminaison.

Préserver l’attribution dans l’audit et les opérations asynchrones

Un journal utile permet de reconstituer les événements sans confondre les identités. Pour chaque événement pertinent, conservez l’acteur, le principal représenté, l’action, le type et l’identifiant de la ressource, la date, le résultat et la référence à la délégation appliquée. Selon le niveau de risque, consignez également le motif de l’opération ou l’identifiant de corrélation. Évitez d’enregistrer des secrets ou des données personnelles inutiles dans l’historique.

L’attribution doit être préservée dans les files d’attente et les tâches en arrière-plan. Si une requête déléguée planifie une tâche, le message devrait transporter un contexte vérifiable comprenant l’acteur, le principal et la référence d’autorisation, plutôt que de dépendre de la session web, qui ne sera plus disponible. Lors de l’exécution de la tâche, décidez s’il faut vérifier à nouveau que la délégation est toujours active. Pour une action qui peut encore être annulée, une vérification au moment de l’exécution évite généralement qu’une révocation laisse une tâche en attente avec une autorisation obsolète. Si l’opération est déjà irréversiblement engagée, documentez cette limite et consignez le moment où l’autorisation a été accordée.

Protégez les journaux contre les modifications non autorisées et limitez les personnes qui peuvent les consulter. L’audit doit faciliter les enquêtes et la responsabilisation, mais ne doit pas devenir une copie indiscriminée des données opérationnelles.

Intégrer l’expiration et la révocation au flux

L’expiration et la révocation ne se résument pas à des changements d’état dans une interface. Une session qui conserve un contexte de délégation peut continuer à afficher d’anciennes options ; l’autorisation côté serveur doit donc vérifier l’état en vigueur à chaque requête, même si l’interface est également mise à jour. Si les permissions sont mises en cache, définissez comment les invalider et quel délai maximal est acceptable avant qu’une révocation prenne effet.

Lors de la révocation, consignez qui l’a effectuée et à quel moment. Évaluez explicitement les sessions actives, les jetons émis, les tâches en file d’attente et les liens temporaires associés. Ne supposez pas que la fermeture d’une session ou la modification d’une donnée en base invalide automatiquement tous ces éléments. La réponse appropriée dépend de la conception, mais elle doit être définie avant la mise en production du flux.

Tester les limites et les cas souvent négligés

Les tests doivent vérifier aussi bien les actions autorisées que celles qui sont refusées. Incluez au minimum les cas d’une délégation pas encore en vigueur, expirée ou révoquée ; d’un acteur différent de celui qui est autorisé ; d’une ressource hors périmètre ; d’une action non accordée ; d’un principal incorrect ou ne disposant pas d’un accès ordinaire à la ressource ; et d’un accès direct à des points de terminaison que l’interface n’affiche pas. Incluez également un cas positif où l’acteur ne dispose pas d’un accès propre à la ressource, mais où le principal y a accès et où la délégation couvre l’action et la ressource. Vous vérifierez ainsi que le système ne confond pas les permissions propres de l’acteur avec l’autorité déléguée.

Ajoutez des tests portant sur les limites temporelles, les modifications concurrentes et les effets indirects. Vérifiez, par exemple, ce qui se passe si une délégation est révoquée alors qu’une opération est en cours ou qu’une tâche est en attente, et si une action sur une tâche déclenche des notifications, des exportations ou des modifications secondaires. Vérifiez que ces effets conservent l’attribution correcte et n’élargissent pas le périmètre.

Distinguiez les tests unitaires de la politique d’autorisation des tests d’intégration qui parcourent les routes, la persistance et les files d’attente. Un test qui vérifie uniquement la méthode de décision ne prouve pas que toutes les routes l’appellent ; un test d’interface ne prouve pas non plus que le serveur est protégé.

Liste de vérification avant la mise en production

• L’acteur et le principal représenté sont-ils clairement distingués dans le code, l’interface et l’audit ?
• Chaque délégation limite-t-elle les actions, les ressources et la durée, et les combinaisons non valides sont-elles empêchées ?
• La politique vérifie-t-elle l’accès du principal et limite-t-elle l’acteur au périmètre délégué, sans exiger qu’il dispose d’un accès propre à la ressource ?
• Chaque opération côté serveur vérifie-t-elle l’identité, l’état, la durée, le périmètre et l’action ?
• La révocation affecte-t-elle les sessions, les jetons, les caches et les tâches en attente conformément à une politique définie ?
• Les journaux permettent-ils d’attribuer les actions sans stocker d’informations inutiles ?
• Les tests couvrent-ils les refus, les limites temporelles, les délégations valides sans accès propre de l’acteur et les effets indirects ?

Une délégation est sécurisée lorsqu’elle n’est pas confondue avec un accès au compte d’autrui et que chaque action peut être justifiée par l’autorité du principal et par une délégation en vigueur et limitée. Si l’équipe ne peut pas répondre précisément aux questions suivantes — qui a agi, au nom de qui, sur quelle ressource et avec quelle permission —, le flux nécessite encore d’être conçu avant sa mise en production.