- Authentification : le processus consistant à déterminer si le demandeur (un utilisateur ou une application) est bien celui ou celle qu’il/elle prétend être.
- Autorisation : le processus consistant à déterminer ce qui est autorisé, selon le demandeur, les autorisations qui lui ont été accordées et/ou l’ensemble des critères d’accès spécifiques au contexte.
- Consentement : les autorisations que l’utilisateur (propriétaire de la ressource) a données à une application pour qu’elle agisse en son nom. Il s’agit généralement d’une exigence d’autorisation déléguée. L’utilisateur doit autoriser le client à accéder à ses données dans un autre système.
- Application des politiques : Il s’agit de l’application des politiques de l’application ou de l’API, en rejetant ou en autorisant l’accès sur la base des informations d’authentification et/ou d’autorisation de l’utilisateur.
- La première catégorie est celle où l’accès est accordé ou refusé à une application ou à une API dans son intégralité. Les données nécessaires à l’application de cette règle et le processus d’application sont généralement définis dans le contexte du serveur d’autorisation. Par exemple, en utilisant les
app_metadataassociées à un utilisateur et une Règle définie dans votre locataire Auth0. - La deuxième catégorie est celle où l’accès est accordé ou refusé à un sous-ensemble spécifique d’applications ou de fonctionnalités API. Les données nécessaires à l’application de cette règle sont généralement stockées dans le serveur d’autorisation. Par exemple, en utilisant des
app_metadatasur un utilisateur dans votre locataire Auth0, le processus d’application étant réalisé dans l’application ou l’API elle-même. Dans ce scénario, les données sont généralement communiquées sous la forme d’une ou plusieurs demandes personnalisées dans un jetonidouaccess. - La troisième catégorie est celle où l’accès est accordé ou refusé en fonction de ce que le demandeur (sujet) peut faire dans le contexte d’une application ou d’une API. Les données nécessaires à cet effet et le processus d’application sont généralement définis dans le contexte de l’application ou de l’API. Dans ce scénario, les données communiquées sous la forme d’une ou plusieurs demandes personnalisées dans un jeton
idouaccesspeuvent être consommées avec ou sans données provenant d’une source externe qui n’est pas Auth0.
- Existe-t-il des scénarios dans lesquels l’accès à l’ensemble d’une application ou d’une API doit être refusé?
- Allez-vous fournir des API auxquelles des applications tierces peuvent accéder?
- Vos API seront-elles également accessibles à vos propres applications (de première partie)?
- Votre application appellera-t-elle une API tierce?
- Vos applications et/ou vos API doivent-elles appliquer un contrôle d’accès basé sur les demandes des utilisateurs?
- Que faire si j’ai besoin de savoir à quelle organisation un jeton d’accès ou un jeton d’ID est associé?
UnauthorizedError lorsque, par exemple, un utilisateur tente d’accéder à une application ou à une API à un moment incorrect (comme décrit dans cet exemple), ou si l’utilisateur n’a pas la ou les bonnes demandes contenues dans ses app_metadata. Pour une application utilisant OpenID Connect (OIDC), cela empêcherait l’attribution du jeton d’ID utilisé pour autoriser l’accès. De même, pour une API, l’attribution d’un jeton d’accès Oauth2 (utilisé lors de l’appel à l’API), peut être empêchée comme décrit dans cet exemple.
Meilleure pratique Dans l’ensemble, nous avons constaté que OIDC est le protocole standard le plus couramment utilisé par les clients d’Auth0 lorsqu’il s’agit d’authentification dans leurs applications. Nous avons également constaté que, même si [OAuth2] (protocols/oauth2) a été créé en tant que protocole de délégation, il est couramment utilisé dans les applications de première partie lorsqu’il existe une API qui n’a pas de session partagée avec l’application. :::
Auth0 peut également fournir les informations nécessaires pour qu’une application puisse appliquer des restrictions. Pour une intégration au niveau de l’application, Auth0 vous permet d’ajouter des demandes personnalisées à un jeton d’ID, que votre application peut ensuite vérifier et utiliser pour appliquer des politiques. Dans ce cas, vous devrez décider des informations dont vous avez besoin pour que votre application prenne des décisions en matière d’application des politiques. Si vous devez prendre des décisions au niveau d’une API plutôt que dans votre application, vous devrez probablement utiliser un jeton d’accès plutôt qu’un jeton d’ID. Poursuivez la lecture pour en savoir plus.Au moment de décider des données à inclure dans votre jeton d’ID et/ou votre jeton d’accès, tenez compte de la taille du jeton, en particulier si vous transmettez le jeton dans l’URL. Même si vous ne transmettez pas de jetons dans l’URL, vous devez également prendre en compte le risque d’exposer des informations personnelles identifiables (Personally Identifiable Information/PII) sensibles. Les informations contenues dans le jeton ne sont pas chiffrées. Par conséquent, bien que la fuite d’un jeton d’ID ne pose généralement pas de problème de sécurité, elle peut devenir un problème de confidentialité en fonction des données incluses dans le jeton.
Meilleure pratique
Lorsque vous décidez d’utiliser des permissions par le biais de demandes personnalisées ou de permissions, assurez-vous de bien comprendre la nature et l’objectif des permissions. Il y a un bon [article de blog] (https://auth0.com/blog/on-the-nature-of-oauth2-scopes/) à ce sujet, qui est facile à lire et qui permet de clarifier le sujet. Dans les scénarios multi-organisations, il peut souvent être important de savoir à quelle organisation s’applique un jeton d’accès (ou même un jeton d’ID). Le respect des meilleures pratiques peut vous faire gagner du temps et de l’énergie.Intégration d’une application
Dans ce scénario, votre locataire Auth0 fournit un jeton comme indicateur de l’accès autorisé à une application. Pour les applications utilisant OpenID Connect (OIDC), le protocole standard de l’industrie que nous trouvons généralement le plus utilisé lorsqu’il s’agit d’applications orientées client, serait un jeton d’ID exprimé sous la forme d’un JWT.Demandes relatives aux jetons d’ID
Grâce à l’extensibilité des règles, Auth0 vous permet d’ajouter des demandes personnalisées à un jeton d’ID facilement, par exemple sur la base du contenu des métadonnées d’un utilisateur. Votre application peut alors vérifier le jeton d’ID pour les demandes concernées, et autoriser ou empêcher l’accès à certaines fonctionnalités selon les besoins. Bien que le processus d’ajout de demandes personnalisées via une règle soit simplifié, le moteur de règles est flexible et vous permet d’écrire un code personnalisé qui peut avoir des effets négatifs. C’est pourquoi il est important de suivre nos conseils sur les meilleures pratiques en matière de règles chaque fois que vous utilisez cette fonction d’extensibilité.Meilleure pratique Lorsque vous envisagez d’ajouter des demandes personnalisées, nous vous conseillons de stocker toutes les données de contrôle d’accès que vous pourriez avoir besoin d’inclure dans les demandes en tant que partie de la [app_metadata] de l’utilisateur (/users/concepts/overview-user-metadata). Tout d’abord, cela vous évite d’avoir à appeler une API externe pour récupérer les données, ce qui peut avoir un impact négatif sur les performances et l’évolutivité de la séquence de connexion. Deuxièmement, les app_metadata **ne peuvent pas** être modifiées par un utilisateur - l’utilisateur ne peut donc pas contourner directement les restrictions de contrôle d’accès en modifiant ses propres métadonnées. N’oubliez pas non plus de consulter nos recommandations sur les [Meilleures pratiques en matière de métadonnées] (architecture-scenarios/b2b/profile-management#metadata). :::
Si vous créez différentes instances de votre application pour les organisations de vos clients, une pratique courante consiste à créer une demande personnalisée dans votre jeton d’ID pour représenter l’organisation de l’utilisateur. Par exemple :
Permissions des jetons d’ID
Les permissions OIDC sont généralement utilisées par une application pour obtenir le consentement à l’accès autorisé aux données d’un utilisateur lors de l’authentification. Chacune des permissions prédéfinies renvoie l’ensemble des demandes standard lorsqu’elles sont définies et telles qu’elles sont décrites dans la spécification OIDC. Les permissions qu’une application demande dépendent des attributs de l’utilisateur dont l’application a besoin. Une fois que les permissions demandées sont autorisées par l’utilisateur, les demandes sont renvoyées dans le jeton d’ID et sont également mises à disposition via le point de terminaison /userinfo.Intégration d’une API
Dans ce scénario, votre locataire Auth0 peut fournir un jeton d’accès OAuth2, généralement sous la forme d’un JWT, qui peut être utilisé par votre API pour restreindre l’accès à certains utilisateurs. De plus, Auth0 prend en charge ce qui est généralement appelé des Applications de première et de tierce parties. Agissant en tant que serveur d’autorisation et avec le consentement de l’utilisateur (le propriétaire de la ressource), votre locataire Auth0 peut être utilisé pour fournir un jeton d’accès, généralement exprimé sous la forme d’un JWT à une application (client) afin qu’elle puisse accéder à des ressources protégées hébergées par un serveur de ressources au nom du propriétaire de la ressource. Le jeton d’accès émis est généralement transmis en tant que jeton du porteur dans l’en-tête d’autorisation HTTP envoyé à une API. Que vous ayez une seule API, ou peut-être une suite d’API de microservices, vous pouvez exploiter les jetons d’accès qu’Auth0 fournit afin de sécuriser l’accès à vos services. Bien que cela soit relativement facile à mettre en place dans le Auth0 Dashboard ou via la Management API Auth0, il est important d’examiner les différents scénarios d’application et les dispositions de l’API afin de déterminer la meilleure architecture pour votre système.Les jetons d’accès OAuth2 sont principalement conçus pour sécuriser les API publiques; lorsqu’il est exprimé sous la forme d’un JWT, un jeton d’accès est une entité autonome qui peut être vérifiée sans qu’il soit nécessaire d’effectuer un appel supplémentaire à une API tierce. Si vos API n’entrent pas dans cette catégorie – par exemple, si elles font partie d’une application (c’est-à-dire qu’elles ne sont appelées que par cette application) ou qu’elles sont placées derrière votre pare-feu – alors les protéger avec des jetons peut s’avérer excessif, et votre flux de travail actuel basé sur les témoins (et autres) peut suffire.
Bien que vous puissiez configurer vos applications pour qu’elles soient de premier niveau et ensuite configurer vos API pour permettre aux clients de premier niveau d’ignorer le consentement, si vous utilisez
localhost , Auth0 ne peut pas vérifier que l’application est réellement une application de premier niveau : vos utilisateurs seront donc tout de même invités à donner leur consentement. Pour contourner cette contrainte, lorsque vous effectuez des tests sur votre machine locale pendant le développement, créez un faux nom d’hôte local et utilisez-le à la place.Demandes de jetons d’accès
Comme pour les jetons d’ID, vous pouvez ajouter des demandes personnalisées aux jetons d’accès en utilisant l’extensibilité de la règle Auth0. Une fois ajoutée, votre API peut alors vérifier le jeton d’ID pour les demandes concernées, et autoriser ou empêcher l’accès à certaines fonctionnalités selon les besoins.Meilleure pratique Lorsque vous envisagez d’ajouter des demandes personnalisées, nous vous conseillons de stocker toutes les données de contrôle d’accès que vous pourriez avoir besoin d’inclure dans les demandes en tant que partie de la [app_metadata] de l’utilisateur (/users/concepts/overview-user-metadata). Tout d’abord, cela vous évite d’avoir à appeler une API externe pour récupérer les données, ce qui peut avoir un impact négatif sur les performances et l’évolutivité. Ensuite, les app_metadata **ne peuvent pas** être modifiées par un utilisateur - l’utilisateur ne peut donc pas contourner directement les restrictions de contrôle d’accès en modifiant ses propres métadonnées. N’oubliez pas non plus de consulter nos conseils [meilleures pratiques en matière de métadonnées] (architecture-scenarios/b2b/profile-management#metadata) guidance too. :::
Permissions des jetons d’accès
Les permissions OAuth2 sont généralement utilisées comme mécanisme permettant à une API de déterminer quelles actions peuvent être effectuées au nom d’un utilisateur. Les permissions peuvent être ajoutées pour chaque API afin de définir des autorisations d’accès spécifiques dans le ou via la Auth0 . Les permissions peuvent également être manipulées via l’extensibilité Auth0 (p. ex. via une règle, comme dans cet exemple). Les permissions qu’une application demande pour accéder à une API doivent dépendre de la fonctionnalité pour lesquelles l’application a besoin que l’utilisateur lui donne la permission d’utiliser. Une fois que les permissions demandées sont autorisées, elles sont transmises au jeton d’accès, qui peut ensuite être vérifié par ladite API. En voici un bon exemple : lorsque vous vous connectez à une application qui utilise un fournisseur social pour la connexion; l’API du fournisseur social nécessite que l’application spécifie si l’utilisateur souhaite que l’application publie des articles en son nom. Cela permet à l’utilisateur d’accepter ou de refuser cette demande. Cet exemple montre comment l’utilisateur délègue une autorisation à l’application, ce qui est différent de l’API qui restreint l’accès en fonction du rôle de l’utilisateur et doit être traité différemment.Meilleure pratique
Même si vous avez la possibilité de manipuler entièrement les permissions des jetons d’accès grâce à l’extensibilité d’Auth0, la meilleure pratique en matière de sécurité consiste à ne supprimer que les permissions qui ne sont pas autorisées et à ne pas ajouter de permissions qui n’ont pas été demandées. Bien que les permissions soient souvent utilisées pour renforcer les autorisations d’accès d’un utilisateur, il existe des situations où leur utilisation peut s’avérer délicate. Nous vous recommandons donc d’utiliser les permissions dans le but pour lequel elles ont été conçues (c’est-à-dire déléguer des autorisations à une application) et d’utiliser des demandes personnalisées pour vos scénarios de contrôle d’accès basés sur les rôles ou d’autres scénarios.Autorisation affinée
L’autorisation affinée vous permet d’accorder à des utilisateurs individuels l’accès à une ressource ou un objet spécifique en fonction de ce qui suit :- Le rôle d’un utilisateur au sein d’une organisation, tel qu’un
editorou unadmin - Un attribut de l’utilisateur ou de l’objet, tel que
managerpour un utilisateur oumarketingpour un objet - Une relation entre un utilisateur et un objet, par exemple un utilisateur disposant d’un accès en visualisation à un dossier parent dispose également d’un accès en visualisation au dossier enfant
RBAC (Contrôle d’accès basé sur les rôles)
Auth0 prend par défaut en charge le Role Based Access Control (RBAC). Le RBAC consiste à attribuer des autorisations aux utilisateurs en fonction de leur rôle au sein d’une organisation, et permet un contrôle d’accès plus simple en offrant une approche plus facile à gérer et moins sujette aux erreurs. La fonctionnalité principale du RBAC peut être utilisée dans de nombreux scénarios multi-organisations. Consultez Données d’organisation dans un jeton d’accès pour plus d’informations sur la façon de s’assurer que votre configuration peut répondre à vos besoins en matière de RBAC.Autorisations machine-machine (M2M)
De nombreux scénarios nécessitent qu’une application sans session interactive avec l’utilisateur obtienne un jeton d’accès afin d’appeler une API. Dans de tels scénarios, vous devez authentifier le client au lieu de l’utilisateur, et 2 fournit le type d’autorisation des identifiants client pour faciliter cette tâche. Voici quelques exemples courants de situations où cela est nécessaire :- Une tâche cron ou un autre service qui doit communiquer avec votre API (par exemple, lorsqu’un rapport quotidien doit être généré et envoyé par courriel à un administrateur).
- Une API distincte qui prend en charge l’accès privilégié (c’est-à-dire que l’API n’est pas exposée directement aux utilisateurs, mais uniquement à un système dorsal).
- Dans certaines architectures de microservices, lorsque certaines couches d’API doivent communiquer avec d’autres couches d’API sans l’intervention d’un utilisateur, ou après l’expiration d’un jeton d’utilisateur.
- Une API privilégiée qui peut devoir être appelée avant qu’un utilisateur ne se soit authentifié (par exemple, à partir d’une règle ou d’un script de base de données personnalisé dans votre locataire Auth0).
Meilleure pratique Traditionnellement, un « compte de service » spécial aurait été créé pour répondre à ces scénarios : un utilisateur avec un nom d’utilisateur et un mot de passe configurés pour les services qui prenaient en charge des cas d’utilisation non interactifs. Cette approche n’est plus conseillée pour de nombreuses raisons, et la meilleure pratique actuelle est d’utiliser le OAuth 2.0 Client Credentials Grant (Octroi d’identifiant client OAuth 2.0 dans ces situations. :::
Données d’organisation dans un jeton d’accès
Si vous disposez d’une API distincte de votre application dans votre système qui prend en charge votre application multi-organisations, il est important de limiter les opérations à l’organisation pour laquelle le jeton a été généré. Pour ce faire, le jeton d’accès doit contenir des informations permettant d’indiquer à l’API l’organisation pour laquelle le jeton d’accès a été émis. Cela peut se faire de différentes manières, en fonction des réponses à quelques questions simples :- Les utilisateurs finaux de cette organisation auront-ils potentiellement plus d’une organisation, ou chaque utilisateur final est-il isolé dans une organisation spécifique?
- Autoriserez-vous un accès machine-machine (M2M) à votre API?
- Si vous autorisez l’accès machine-machine (M2M) à votre API, y aura-t-il des développeurs qui auront besoin d’un ID et d’un secret client uniques pour accéder à plusieurs organisations (mais pas à toutes les organisations)?
- Autoriserez-vous la création d’applications tierces nécessitant un consentement?
- Tout d’abord, vous pouvez transmettre l’audience à Auth0 en tant que paramètre de première classe, sans avoir à créer de paramètre personnalisé. L’avantage est qu’Auth0 contribuera à renforcer l’existence de l’audience et la transmettra à vos règles. Ensuite, cela garantit également qu’un jeton d’actualisation délivré ne fonctionnera que pour l’audience spécifique auquel il a été délivré à l’origine.
- Cela vous permet de restreindre les autorisations des clients à des organisations spécifiques dès le départ. L’autre solution consiste à créer un hook client plus compliqué pour tenter de récupérer les restrictions à partir d’un autre endroit, ce qui nécessite également un moyen beaucoup plus complexe et potentiellement problématique pour indiquer à l’appel d’identification du client l’organisation pour laquelle le jeton d’accès doit être délivré.
- Cela vous permet également d’utiliser la fonctionnalité principale de RBAC avec Auth0 et de vous assurer que les utilisateurs finaux qui ont accès à plus d’une organisation peuvent avoir un rôle potentiellement différent pour chaque organisation.