Flux d’accès utilisateur vs flux d’accès client
- Accès client : utilisé pour l’accès machine à machine, qui correspond au Client Credentials Flow.
- Accès utilisateur : utilisé pour tous les flux d’accès qui génèrent un jeton d’accès associé à un utilisateur final, ce qui permet à l’application d’accéder à une API au nom de l’utilisateur. Les flux d’accès utilisateur n’incluent pas le Client Credentials Flow. Pour en savoir plus sur les flux d’accès utilisateur, consultez Authentication and Authorization Flows.
Stratégies d’accès des applications aux API
| Stratégie | Description | Flux d’accès |
|---|---|---|
allow_all | Lorsqu’elle est configurée pour une API, toute application de votre tenant peut obtenir un jeton d’accès pour l’API. Aucun grant spécifique n’est requis. | Valeur par défaut pour les flux d’accès utilisateur lorsque vous créez une API. Vous pouvez uniquement configurer allow_all pour les flux d’accès utilisateur. |
require_client_grant | Lorsqu’elle est configurée pour une API, seules les applications avec un client grant défini peuvent obtenir un jeton d’accès pour l’API. Le client grant établit les permissions maximales qu’une application peut demander à l’API. Pour en savoir plus sur la création et la gestion des client grants, consultez Application Access to APIs: Client Grants. | Valeur par défaut pour le flux Client Credentials Flow lorsque vous créez une API. |
deny_all | Lorsqu’elle est configurée pour une API, aucune application ne peut obtenir un jeton d’accès pour l’API, quelles que soient les autres configurations ou grants. L’accès est complètement restreint. | Vous pouvez configurer deny_all pour les flux d’accès utilisateur et client. |
require_client_grant, qui suit une approche basée sur le principe du moindre privilège. Pour en savoir plus, consultez Application Access to APIs: Client Grants.
Lorsque vous définissez la stratégie d’accès des applications d’une API sur require_client_grant, vous devez fournir explicitement les scopes requis dans la requête de jeton. Cela ne s’applique pas aux requêtes de jeton d’actualisation où, si vous omettez les scopes, le Serveur d’autorisation suppose que l’application souhaite obtenir tous les scopes qui lui ont été accordés dans le jeton d’accès d’origine. En conséquence, le Serveur d’autorisation renvoie un jeton d’accès avec les mêmes scopes que ceux accordés initialement par le propriétaire de la ressource.
Configurer la stratégie d’accès des applications à l’API
subject_type_authorization dans la collection resource-servers.
L’objet subject_type_authorization contient deux objets imbriqués, user et client, chacun avec un attribut de stratégie que vous pouvez définir sur l’une des trois stratégies d’accès décrites dans Stratégies d’accès des applications à l’API.
API existante
PATCH vers le point de terminaison /resource-servers/{id} et transmettez un objet subject_type_authorization qui spécifie les stratégies pour les types d’accès utilisateur et client.
L’exemple de code suivant montre comment définir différentes stratégies d’accès pour les types d’accès utilisateur et client pour une API existante :
- La stratégie utilisateur est définie sur
require_client_grant, ce qui signifie que les applications doivent disposer d’un client grant pour accéder à l’API au nom de l’utilisateur. - La stratégie client est définie sur
deny_all, ce qui restreint l’accès machine-à-machine à cette API.
Nouvelle API
POST vers le point de terminaison /resource-servers et transmettez un objet subject_type_authorization qui spécifie les stratégies pour les types d’accès utilisateur et client.
L’exemple de code suivant montre comment définir différentes stratégies d’accès pour les types d’accès utilisateur et client lors de la création d’une nouvelle API :
- La stratégie utilisateur est définie sur
require_client_grant, ce qui signifie que les applications doivent avoir une autorisation client pour accéder à l’API au nom de l’utilisateur. - La stratégie client est définie sur
deny_all, ce qui restreint l’accès machine-à-machine à cette API.