- Authentification : le processus qui consiste à déterminer si un principal (un utilisateur ou une application) est bien celui ou celle qu’il ou elle prétend être.
- Autorisation : le processus qui consiste à déterminer ce qui est permis, en fonction du principal, des permissions qui lui ont été accordées et/ou de l’ensemble des critères d’accès contextuels applicables.
- Consentement : les permissions que l’utilisateur () 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 au client la permission d’accéder à ses données dans un autre système.
- Application des politiques : le fait d’appliquer les politiques de l’application ou de l’API en rejetant ou en autorisant l’accès selon les renseignements d’authentification et/ou d’autorisation de l’utilisateur.
- La première catégorie est celle où l’accès à une application ou à une API dans son ensemble est soit accordé, soit refusé. Les données nécessaires à cette application et le processus d’application lui-même sont généralement définis dans le contexte de l’Authorization Server. Par exemple, en utilisant
app_metadataassocié à un utilisateur et une Action définie dans votre tenant Auth0. - La deuxième catégorie est celle où l’accès à un sous-ensemble précis des fonctionnalités d’une application ou d’une API est soit accordé, soit refusé. Les données nécessaires à cette application sont généralement stockées dans l’Authorization Server. Par exemple, en utilisant
app_metadatapour un utilisateur dans votre tenant Auth0, tandis que l’application est effectuée dans l’application ou l’API elle-même. Dans ce scénario, les données sont généralement transmises sous la forme d’une ou de plusieurs claims personnalisées dans un jetonidouaccess. - La troisième catégorie est celle où l’accès est soit accordé, soit refusé selon ce sur quoi le principal (subject) peut agir dans le contexte d’une application ou d’une API. Les données nécessaires à cette application, tout comme le processus d’application, sont généralement définies dans le contexte de l’application ou de l’API. Dans ce scénario, les données transmises sous la forme d’une ou de plusieurs claims personnalisées dans un jeton
idouaccesspeuvent être utilisées avec ou sans données provenant d’une source externe autre qu’Auth0.
- Existe-t-il des scénarios où l’accès à une application ou à une API entière devrait être refusé ?
- Fournirez-vous des API auxquelles des applications tierces peuvent accéder ?
- Vos API seront-elles aussi accessibles par vos propres applications (de première partie) ?
- Votre application effectuera-t-elle des requêtes à une API tierce ?
- Vos applications ou API devraient-elles appliquer un contrôle d’accès fondé sur les claims des utilisateurs ?
api.access.deny() lorsque, par exemple, un utilisateur tente d’accéder à une application ou à une API au mauvais moment (comme décrit dans cet exemple) — ou si l’utilisateur n’a pas le ou les voulus dans son app_metadata. Pour une application qui utilise OpenID Connect (OIDC), cela empêcherait l’émission du ID Token utilisé pour autoriser l’accès. De même, pour une API, l’émission de tout jeton OAuth2 jeton d’accès (utilisé lors d’une requête à l’API) pourrait être empêchée, comme décrit dans cet exemple.
De façon générale, nous avons constaté qu’OIDC est le protocole standard de l’industrie le plus couramment utilisé par les clients d’Auth0 pour l’authentification dans leurs applications. Nous avons aussi constaté que, même si OAuth2 a été conçu comme un protocole de Delegation, il est couramment utilisé dans des applications de première partie lorsqu’une API ne partage pas de session avec l’application.
Au moment de décider si vous devriez utiliser des permissions par l’intermédiaire de claims personnalisées ou de scopes, assurez-vous de bien comprendre la nature et l’objectif des scopes. Il existe un excellent article de blogue à ce sujet, facile à lire et utile pour clarifier la question.
Intégration au niveau de l’application
Dans ce scénario, votre tenant Auth0 fournit un jeton comme preuve d’accès autorisé à une application. Pour les applications qui utilisent OpenID Connect (OIDC), le protocole standard de l’industrie que nous voyons généralement le plus souvent dans les applications destinées aux clients, il s’agirait d’un ID Token présenté sous forme de JWT.Claims du ID Token
Grâce à l’extensibilité des Actions, Auth0 vous permet d’ajouter facilement des claims personnalisées à un ID Token en fonction, par exemple, du contenu des métadonnées d’un utilisateur. Votre application peut ensuite vérifier que le ID Token contient les claims nécessaires, puis autoriser ou refuser l’accès à certaines fonctionnalités, selon le cas. Notez que, même si le processus d’ajout de claims personnalisées au moyen d’une Action est simplifié, le runtime des Actions est flexible et vous permet d’écrire du code personnalisé qui pourrait avoir des effets négatifs.Si vous envisagez d’ajouter des claims personnalisées, nous vous recommandons de stocker dans le
app_metadata de l’utilisateur toutes les données de contrôle d’accès que vous pourriez devoir inclure dans les claims. D’abord, cela vous évite d’avoir à faire une requête à une API externe pour récupérer ces données, ce qui peut nuire aux performances et à l’évolutivité de la séquence de connexion. Ensuite, app_metadata ne peut pas être modifié par un utilisateur; celui-ci ne peut donc pas contourner directement les restrictions de contrôle d’accès en modifiant ses propres . N’oubliez pas non plus de consulter nos conseils sur les pratiques exemplaires en matière de métadonnées.Scopes d’ID Token
Les scopes OIDC sont généralement utilisés par une application pour obtenir le consentement permettant d’accéder aux renseignements d’un utilisateur pendant l’authentification. Chacun des scopes prédéfinis renvoie l’ensemble des claims standard, lorsqu’ils sont définis, comme décrit dans la spécification OIDC. Les scopes qu’une application request dépendent des attributs utilisateur dont elle a besoin. Une fois les scopes demandés autorisés par l’utilisateur, les claims sont renvoyés dans l’ID Token et sont également accessibles par l’intermédiaire du endpoint /userinfo.intégration au niveau de l’API
Dans ce scénario, votre tenant Auth0 peut fournir un OAuth2 jeton d’accès, généralement sous la forme d’un JWT, que votre API peut utiliser pour restreindre l’accès à certaines parties. De plus, Auth0 prend en charge ce qu’on appelle généralement les applications de première partie et de tierce partie. En agissant comme serveur d’autorisation, et avec le consentement de l’utilisateur (le propriétaire de la ressource), votre tenant Auth0 peut fournir un jeton d’accès — généralement sous la forme d’un JWT — à une application (client) afin qu’elle puisse accéder à une ressource protégée hébergée par un au nom du propriétaire de la ressource. Le jeton d’accès émis est généralement transmis comme jeton Bearer dans l’en-tête HTTP Authorization envoyé à une API. Que vous ayez une seule API ou une suite d’API de microservices logiquement liées, vous pouvez tirer parti des jetons d’accès fournis par Auth0 afin de sécuriser l’accès à votre ou vos services. Même s’il est relativement facile de configurer cela dans l’Auth0 Dashboard ou au moyen de l’Auth0 Management API, il est important d’examiner les différents scénarios d’application et modèles d’API afin de déterminer l’architecture la mieux adaptée à votre système.Les jetons d’accès OAuth2 sont principalement conçus pour sécuriser des API accessibles publiquement; lorsqu’il est présenté 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 d’API tiers supplémentaire. Si vos API n’entrent pas dans cette catégorie — c.-à-d. qu’elles font partie de l’application elle-même (autrement dit, qu’elles sont appelées uniquement par cette application) ou qu’elles se trouvent derrière votre pare-feu — alors les protéger avec des jetons pourrait être excessif, et votre workflow actuel fondé sur des témoins (et autres mécanismes) pourrait suffire.
Claims du jeton d’accès
Comme pour les ID Tokens, vous pouvez ajouter des claims personnalisées aux jetons d’accès à l’aide du mécanisme d’extensibilité des Actions d’Auth0. Une fois ajoutés, votre API peut vérifier si un jeton d’accès contient les claims requis, puis autoriser ou refuser l’accès à certaines fonctionnalités, selon le besoin.Si vous envisagez d’ajouter des claims personnalisées, nous vous recommandons de stocker dans l’
app_metadata de l’utilisateur toutes les données de contrôle d’accès que vous pourriez devoir inclure dans les claims. D’une part, cela vous évite d’avoir à effectuer une requête vers une API externe pour récupérer ces données, ce qui peut nuire aux performances et à l’évolutivité. D’autre part, l’app_metadata ne peut pas être modifié par un utilisateur; celui-ci 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 sur les best practices relatives aux métadonnées.Scopes du jeton d’accès
Les scopes OAuth2 servent généralement de mécanisme permettant à une API de déterminer quelles peuvent être exécutées au nom d’un utilisateur. Des scopes peuvent être ajoutées pour chaque API afin de définir des permissions d’accès précises dans le ou au moyen de la d’Auth0. Les scopes peuvent aussi être modifiées au moyen de l’extensibilité d’Auth0 (p. ex. au moyen d’une Action, comme dans cet exemple). Les scopes qu’une application demande pour accéder à une API devraient dépendre des fonctionnalités pour lesquelles l’utilisateur doit autoriser l’application à les utiliser. Une fois les scopes demandées autorisées, elles seront renvoyées dans le jeton d’accès, qui pourra ensuite être validé par cette API. Un bon exemple est celui où vous vous connectez à une application qui utilise un fournisseur social pour l’authentification : l’API du fournisseur social exige que l’application précise si l’utilisateur veut lui permettre de publier du contenu en son nom. Cela permet à l’utilisateur d’accepter ou de rejeter cette requête. Cet exemple montre comment l’utilisateur délègue une permission à l’application — ce qui diffère d’une API qui restreint l’accès selon le de l’utilisateur, et qui devrait être traité différemment. Bien que les scopes soient souvent utilisées comme moyen d’appliquer des permissions d’accès à un utilisateur, il existe des situations où cela peut devenir délicat si vous les utilisez de cette façon. Nous vous recommandons donc d’utiliser les scopes pour l’usage auquel elles sont destinées (c.-à-d. déléguer une permission à une application) et d’utiliser des claims personnalisées pour vos scénarios fondés sur les rôles ou d’autres scénarios de contrôle d’accès.Autorisation fine (FGA)
L’autorisation fine vous permet d’accorder à des utilisateurs précis l’accès à une ressource ou à un objet donné en fonction :- du rôle d’un utilisateur au sein d’une organisation, comme
editorouadmin - d’un attribut de l’utilisateur ou de l’objet, comme
managerpour un utilisateur oumarketingpour un objet - d’une relation entre un utilisateur et un objet; par exemple, un utilisateur ayant accès à un dossier parent en consultation a aussi accès au dossier enfant en consultation
Contrôle d’accès basé sur les rôles (RBAC)
Auth0 offre une prise en charge intégrée du contrôle d’accès basé sur les rôles (RBAC). Le RBAC consiste à attribuer des permissions aux utilisateurs selon leur rôle au sein d’une organisation, et simplifie le contrôle d’accès grâce à une approche plus facile à gérer et moins sujette aux erreurs.Autorisation machine-à-machine (M2M)
Il existe de nombreux scénarios dans lesquels une application sans session utilisateur interactive doit obtenir un jeton d’accès pour effectuer une requête à une API. Dans de tels scénarios, vous devez authentifier le client plutôt que l’utilisateur, et 2 fournit le type de grant client credentials pour y parvenir facilement. Voici quelques exemples courants où cela est nécessaire :- Une tâche cron ou un autre service qui doit communiquer avec votre API (p. ex. lorsqu’un rapport quotidien doit être généré et envoyé par courriel à un administrateur).
- Une API distincte qui prend en charge un accès privilégié (p. ex. l’API n’est pas exposée directement aux utilisateurs, mais uniquement à un backend).
- Dans certaines architectures de microservices, où certaines couches d’API doivent communiquer avec d’autres couches d’API sans 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 soit authentifié (c.-à-d. à partir d’une action ou d’un script DB personnalisé dans votre tenant Auth0)
Traditionnellement, un « compte de service » spécial était créé pour répondre à ces scénarios : un utilisateur avec un nom d’utilisateur et un mot de passe configurés pour des services prenant en charge des cas d’utilisation non interactifs. Cette approche n’est plus recommandée pour de nombreuses raisons, et la meilleure pratique actuelle consiste à utiliser le grant Client Credentials OAuth 2.0 dans ces situations.