Pour des utilisateurs humains, oui mais du coup on est plus vraiment sur du webservice mais plutôt de la webapp. En webservice, on va plutôt utiliser des API keys, des tokens.
OAuth2 est une norme très générique et tu peux l'employer pour faire du webservice de backend à backend :)
La norme UMA 2.0 est justement prévue pour utiliser OAuth2 pour permettre à des tiers d'accéder aux données d'un utilisateur et tout ceci de manière asynchrone (le tiers peut demander l'accès et recevoir l'autorisation de l'utilisateur bien plus tard).
Malheureusement, la norme est assez complexe puis qu'elle définit beaucoup d'acteurs: un utilisateur avec son application, un service d'autorisation et un tiers avec une autre application.
En réalité, tous les acteurs ne sont pas nécessaires dans toutes les implémentations et donc des simplifications peuvent avoir lieu dans les interactions.
Je comprend bien que la norme doit pouvoir gérer les cas les plus complexes (comme l'accès aux dossiers médicaux par des médecins tiers), mais ça je pense que ça la dessert un peu, puisqu'elle est difficile à lire.
Ce que je trouve intéressant avec UMA 2.0 + OAuth 2.0, c'est que les backends sont enregistrés comme Client de OAuth2 (en tout cas avec l'implémentation de Keycloak). Du coup, si un des backends tiers n'est plus de confiance, tu peux juste le désactiver et il n'a plus accès à aucune donnée utilisateur de ton backend.
En plus, il y a un système de "Permission Ticket" qui détermine ce que tu as besoin comme droit pour faire ton action, qui vérifie si ta demande est conforme aux politiques de sécurités actuelles et qui te donne un token d'accès pour une durée limitée. Les politiques de sécurité sont configurables et protègent les ressources et/ou les "scopes".
Pour lier ton backend avec le serveur d'autorisation, il y a la norme UMAFedAuth qui permet de faire vérifier concrètement que les permissions ticket sont valides.
J'ai eu l'occasion de configurer un Keycloak avec tout ça. Grâce à UMA, j'ai évité de ré-inventer un système d'API token et j'ai eu pas mal d'avantages en plus:
Un API token est comme un mot de passe avec une durée illimitée de validité. Je préfère les token d'UMA qui sont limités dans le temps.
Un API token est généré par les utilisateurs. Avec UMA 2.0, si l'utilisateur interagit avec le service d'autorisation, alors il a juste à configurer les accès qu'il donne sans avoir besoin de créer de "mot de passe à copier dans la configuration de l'autre application". Le service d'autorisation se charge lui-même de faire le lien entre les applications tierces et le backend à protéger.
Un API token a une configuration fixe des droits associés. Avec les Permissions Ticket et les Policy, je peux ajuster les droits nécessaires ou les politiques de sécurités avec un peu plus de souplesse: je n'ai pas besoin de refaire générer des tokens à tous les tiers. Je n'ai pas essayé, mais l'utilisateur lui-même doit pouvoir ajuster ses politiques de sécurités.
Un même tiers aura X API tocken et si je veux interdire ce tiers, alors je dois retrouver tous ses API tocken. Avec les systèmes que j'ai vu (chez Github et Gitlab par exemple), il n'y a aucun moyen de désactiver un tiers. Avec Keycloak, j'ai juste à désactiver son Client OAuth.
[^] # Re: Si je puis me permettre ...
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à la dépêche Oubliez les web services, utilisez des tubes nommés. Évalué à 4.
OAuth2 est une norme très générique et tu peux l'employer pour faire du webservice de backend à backend :)
La norme UMA 2.0 est justement prévue pour utiliser OAuth2 pour permettre à des tiers d'accéder aux données d'un utilisateur et tout ceci de manière asynchrone (le tiers peut demander l'accès et recevoir l'autorisation de l'utilisateur bien plus tard).
Malheureusement, la norme est assez complexe puis qu'elle définit beaucoup d'acteurs: un utilisateur avec son application, un service d'autorisation et un tiers avec une autre application.
En réalité, tous les acteurs ne sont pas nécessaires dans toutes les implémentations et donc des simplifications peuvent avoir lieu dans les interactions.
Je comprend bien que la norme doit pouvoir gérer les cas les plus complexes (comme l'accès aux dossiers médicaux par des médecins tiers), mais ça je pense que ça la dessert un peu, puisqu'elle est difficile à lire.
Ce que je trouve intéressant avec UMA 2.0 + OAuth 2.0, c'est que les backends sont enregistrés comme Client de OAuth2 (en tout cas avec l'implémentation de Keycloak). Du coup, si un des backends tiers n'est plus de confiance, tu peux juste le désactiver et il n'a plus accès à aucune donnée utilisateur de ton backend.
En plus, il y a un système de "Permission Ticket" qui détermine ce que tu as besoin comme droit pour faire ton action, qui vérifie si ta demande est conforme aux politiques de sécurités actuelles et qui te donne un token d'accès pour une durée limitée. Les politiques de sécurité sont configurables et protègent les ressources et/ou les "scopes".
Pour lier ton backend avec le serveur d'autorisation, il y a la norme UMAFedAuth qui permet de faire vérifier concrètement que les permissions ticket sont valides.
J'ai eu l'occasion de configurer un Keycloak avec tout ça. Grâce à UMA, j'ai évité de ré-inventer un système d'API token et j'ai eu pas mal d'avantages en plus: