- Authentification : processus visant à déterminer si une entité principale (un utilisateur ou une application) est bien celle ou ce qu’elle prétend être.
- Autorisation : le processus de détermination de ce qui est autorisé, en fonction des règles principales, des permissions qui lui ont été accordées et/ou de l’ensemble des critères d’accès spécifiques en contexte.
- Consentement : les permissions que l’utilisateur (propriétaire des ressources) a accordées à une application pour agir en son nom. Il s’agit généralement d’une exigence de l’autorisation déléguée. L’utilisateur doit donner la permission au Client pour qu’il accède aux données de l’utilisateur dans un autre système.
- Application des politiques : L’acte d’appliquer les politiques de l’application ou de l’API, en rejetant ou en autorisant l’accès en fonction des informations d’authentification et/ou d’autorisation d’un utilisateur.
- La première catégorie est celle où l’accès est soit accordé, soit refusé à une application ou une API dans son intégralité. Les données nécessaires pour appliquer cette catégorie et le processus d’application sont généralement définis dans le contexte du serveur d’autorisations, par exemple, en utilisant
app_metadataassociée à un utilisateur et une règle définie dans votre locataire Auth0. - La deuxième catégorie est celle où l’accès est soit accordé, soit refusé à un sous-ensemble spécifique des fonctionnalités de l’application ou de l’API. Les données nécessaires pour l’application de cette catégorie sont généralement stockées dans le serveur d’autorisations. Par exemple, en utilisant
app_metadatasur un utilisateur dans votre locataire Auth0, avec le processus d’application s’exécutant dans l’application ou l’API elle-même. Dans ce scénario, les données sont généralement communiquées sous forme d’une ou de plusieurs demandes personnalisées dans unidou un jeton d’access - La troisième catégorie est celle où l’accès est soit accordé, soit refusé en fonction de ce sur quoi le principal (sujet) peut agir dans le contexte d’une application ou d’une API. Les données nécessaires pour appliquer cette catégorie, ainsi que 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 forme d’une ou de plusieurs demandes dans un
idou un jeton d’accesspeuvent être utilisées avec ou sans données provenant d’une source externe autre que Auth0.
- Y a-t-il des cas où l’accès à une application ou une API entière devrait être refusé ?
- Fournirez-vous des API qui peuvent être accessibles par des applications tierces ?
- Vos API seront-elles également accessibles par vos propres applications (première partie) ?
- Votre application appellera-t-elle une API tierce ?
- Vos applications et/ou API devraient-elles appliquer le contrôle d’accès en fonction des demandes des utilisateurs ?
UnauthorizedError lorsque, par exemple, un utilisateur tente d’accéder à une application ou à une API à un moment inapproprié (comme décrit dans cet exemple), ou si l’utilisateur ne possède pas 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 de tout jeton d’accès OAuth2 (utilisé lors de l’appel de l’API), pourrait ê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 l’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 allez devoir décider quelles informations sont nécessaires pour que votre application prenne des décisions d’application. Si vous devez prendre des décisions au niveau de l’API plutôt que dans votre application, vous allez devoir probablement utiliser un jeton d’accès au lieu d’un jeton d’ID. Poursuivez la lecture pour plus d’informations.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.Intégration de l’application
Dans ce scénario, votre locataire Auth0 fournit un jeton comme indicateur d’accès autorisé à une application. Pour les applications utilisant OpenID Connect (OIDC), le protocole standard de l’industrie généralement le plus utilisé pour les applications destinées aux clients serait un jeton d’ID exprimé sous forme de JWT.Demandes relatives aux jetons d’ID
En utilisant l’extensibilité des règles, Auth0 vous permet de facilement ajouter des demandes personnalisées à un jeton d’ID en fonction, par exemple, du contenu des métadonnées d’un utilisateur. Votre application peut ensuite vérifier le jeton d’ID pour les demandes nécessaires et soit autoriser, soit empêcher l’accès à certaines fonctionnalités selon les besoins. Notez que, bien que le processus d’ajout de revendications personnalisées via les règles soit simplifié, le moteur des règles est flexible et vous permet d’élaborer du code personnalisé qui peut avoir des effets négatifs. Il est donc important de suivre nos conseils sur les meilleures pratiques en matière de règles chaque fois que vous utilisez cette fonctionnalité 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 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. 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/b2c/profile-management#metadata). :::
Permissions relatives aux jetons d’ID
Lespermissions OIDC sont généralement utilisées par une application pour obtenir le consentement pour un accès autorisé aux détails d’un utilisateur lors de l’authentification. Chacune des permissions prédéfinies renvoie l’ensemble des revendications standard là où elles sont définies, comme décrit 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 accordées par l’utilisateur, les demandes sont renvoyées dans le jeton d’ID et sont également accessibles via le point de terminaison /userinfoIntégration de l’API
Dans ce scénario, votre locataire Auth0 peut fournir un jeton d’accèsOAuth2, généralement exprimé sous forme de JWT, qui peut être utilisé par votre API pour restreindre l’accès à certaines parties. De plus, Auth0 prend en charge ce qui est théoriquement décrit comme Applications de première et de tierce parties. Agissant comme serveur d’autorisations, et avec le consentement de l’utilisateur (le propriétaire des ressources), votre locataire Auth0 peut être utilisé pour fournir un jeton d’accès (généralement exprimé sous forme de 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 des ressources. 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 de microservices API liés de manière logique, vous pouvez tirer parti des jetons d’accès fournis par Auth0 pour sécuriser l’accès à vos services. Bien qu’il soit relativement facile de configurer cela dans Auth0 Dashboard ou via la Management API Auth0, il est important d’examiner les différents scénarios d’application et les structures des API pour 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 relatives aux jetons d’accès
Comme c’est le cas avec les jetons d’ID, vous pouvez ajouter des demandes personnalisées aux jetons d’accès en utilisant l’extensibilité des règles Auth0. Une fois ajoutée, votre API peut ensuite vérifier un jeton d’accès pour les demandes nécessaires et soit autoriser, soit 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 des [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/b2c/profile-management#metadata) :::
Permissions des jetons d’accès
Lespermissions OAuth2 sont généralement utilisées comme le mécanisme par lequel une API peut déterminer les actions susceptibles d’être effectuées au nom d’un utilisateur. Les permissions peuvent être ajoutées pour chaque API afin de définir des permissions d’accès spécifiques dans le ou via Auth0. Les permissions peuvent également être manipulées via l’extensibilité d’Auth0 (par exemple, via une règle, comme dans cet exemple). Les permissions qu’une application nécessite pour accéder à une API devraient dépendre des fonctionnalités pour lesquelles l’application a besoin que l’utilisateur donne l’autorisation de les utiliser. Une fois que les permissions demandées sont autorisées, elles seront renvoyées dans le jeton d’accès qui pourra ensuite être vérifié par ladite API. Un bon exemple de cela est lorsque vous vous connectez à une application qui utilise un fournisseur social pour la connexion : l’API du fournisseur social exige que l’application précise si l’utilisateur souhaite que l’application publie des éléments en son nom. Cela permet à l’utilisateur d’accepter ou de refuser cette demande. Cet exemple présente 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 d’un utilisateur, et cela devrait être géré 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 comme un moyen d’appliquer des permissions d’accès pour un utilisateur, il existe des situations où cela peut devenir problématique lorsque vous les utilisez de cette manière. Nous recommandons donc d’utiliser les permissions pour leur usage prévu (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 autres.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 permet le contrôle d’accès basé sur les rôles(RBAC). RBAC fait référence à l’attribution d’autorisation aux utilisateurs en fonction de leur rôle au sein d’une organisation, et offre un contrôle d’accès plus simple en proposant une approche plus gérable, moins sujette à erreur.Autorisation machine-machine (M2M)
Il existe de nombreux scénarios qui nécessitent qu’une application sans session utilisateur interactive 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’octroi des identifiants client pour faciliter le processus. Quelques exemples courants où cela est nécessaire :- Un job 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é (par exemple, l’API n’est pas exposée directement aux utilisateurs, mais uniquement à un système dorsal).
- Dans certaines architectures de microservices, où certaines couches d’API doivent communiquer avec d’autres sans l’intervention d’un utilisateur, ou après l’expiration d’un jeton utilisateur.
- Une API privilégiée qui peut devoir être appelée avant qu’un utilisateur ne se soit authentifié (c’est-à-dire à partir d’une règle ou d’un script de base de données personnalisé dans votre locataire Auth0).