Les politiques d’accès aux API pour les applications sont actuellement offertes en accès anticipé. En utilisant cette fonctionnalité, vous acceptez les conditions applicables de version d’essai gratuite prévues dans la Convention principale d’abonnement d’Okta.
- Une API identifiée par son
audienceou son identifiant unique. - Une application identifiée par son
client_id. - Une liste d’autorisations, comme des scopes et/ou des
authorization_details_typesque l’application est autorisée à demander pour l’audience spécifiée.
Politiques d’accès à l’API pour les applications et octrois de client
require_client_grant, seules les applications disposant d’un octroi de client défini peuvent obtenir un jeton d’accès pour cette API. L’octroi de client définit les autorisations maximales qu’une application peut demander à l’API en appliquant le principe du moindre privilège. Par conséquent, Auth0 recommande d’utiliser require_client_grant lors de la configuration de la politique d’accès à l’API pour les applications.
Pour illustrer comment les client grants appliquent le principe du moindre privilège, supposons que vous ayez une API Social Media avec les permissions : read:posts, write:posts, read:friends et delete:posts. Vous créez une application et définissez un client grant avec les permissions : read:posts et write:posts.
Ce client grant sert maintenant de plafond maximal. Même si l’API Social Media comporte d’autres permissions, votre application ne pourra jamais demander ou se voir accorder read:friends ou delete:posts.
Flux d’accès utilisateur vs flux d’accès client
subject_type de l’autorisation client détermine le type d’accès d’application autorisé pour une API.
Une application peut avoir jusqu’à deux autorisations client pour une même API :
- Quand vous définissez
subject_typesurclient, vous définissez ses permissions de type machine à machine. - Quand vous définissez
subject_typesuruser, vous définissez ses permissions pour agir au nom de l’utilisateur.
| Type d’accès | Attribut subject_type | Description |
|---|---|---|
| Flux Client Credentials (flux d’accès machine à machine) | Définissez subject_type sur client. | L’autorisation client autorise directement l’application à accéder à l’API en son propre nom plutôt qu’au nom de l’utilisateur final. Les permissions que vous définissez dans l’autorisation client sont celles que l’application est autorisée à recevoir dans le jeton d’accès. |
| Flux d’accès utilisateur | Définissez subject_type sur user. | L’autorisation client définit les permissions maximales que l’application peut demander à l’API. Les permissions finales dans le jeton d’accès émis à l’application au nom de l’utilisateur sont l’intersection des permissions :
Pour en savoir plus sur les flux d’accès utilisateur, consultez Flux d’authentification et d’autorisation. Les flux d’accès utilisateur n’incluent pas le flux Client Credentials. |
Vous pouvez modifier les portées finales accordées par le serveur d’autorisation à l’application ou à l’utilisateur à l’aide des Actions.
Attributs de l’autorisation client
| Attribut | Description |
|---|---|
id | Identifiant unique de l’autorisation client. |
audience | Identifiant unique de l’API à laquelle s’applique l’autorisation client. |
client_id | L’ID unique de l’application à laquelle l’accès est accordé. |
scopes | Un tableau de chaînes de caractères représentant les permissions que l’application peut demander. |
authorization_details_types | Un tableau de chaînes de caractères représentant les types de données d’autorisation détaillées que l’application peut demander. Cet attribut peut uniquement être spécifié pour les flux d’accès utilisateur. |
subject_type | Le type d’accès à l’application que permet l’autorisation client :
|
organization_usage | Détermine comment l’application peut utiliser les organisations lorsqu’elle accède à l’API via le flux d’informations d’identification du client. Les valeurs possibles sont : deny, allow ou require.Pour en savoir plus sur les paramètres d’organisation, consultez Organizations for M2M Applications: Define Organization Behavior. |
allow_any_organization | Détermine si l’application peut accéder à n’importe quelle organisation lorsqu’elle utilise le flux d’informations d’identification du client. Pour en savoir plus sur les paramètres d’organisation, consultez Organizations for M2M Applications: Define Organization Behavior. |
Configurer les autorisations client
/client-grants.
Créer une autorisation client
POST vers le point de terminaison /client-grants.
L’exemple de code suivant crée une autorisation client pour qu’une application accède à l’API https://api.my-service.com. Le subject_type est user, ce qui signifie que l’autorisation client est destinée à l’accès utilisateur et permet à l’application de demander la portée read:item et le type de détails d’autorisation payment.
Mettre à jour une autorisation client
PATCH vers /client-grants/{id}.
L’exemple de code suivant met à jour une autorisation client existante afin d’étendre ses autorisations. L’Application peut maintenant aussi demander la portée update:item et un type supplémentaire de détails d’autorisation credits_transfer.
Supprimer une autorisation de client
DELETE vers /client-grants/{id}.
L’exemple de code suivant supprime l’autorisation de client, ce qui révoque l’accès de l’application à l’API :
Récupérer les autorisations client
client-grants en utilisant des paramètres comme client_id, audience ou subject_type.
L’exemple de code suivant récupère toutes les autorisations client qui permettent l’accès des utilisateurs à l’API https://api.my-service.com.