Flux de code d’autorisation avec demandes d’autorisation poussées (RAR)
Pour utiliser les fonctionnalités de l’identité très réglementée (HRI), vous devez disposer d’un plan Enterprise avec le module complémentaire Identité très réglementée. Consultez Tarification Auth0 pour plus de détails.
LesDemandes d’autorisation poussées (RAR) étendent le protocole OAuth2 pour permettre aux clients de demander et obtenir les données d’autorisation détaillées de la part des propriétaires de ressources, tels que les utilisateurs finaux, pendant le flux de code d’autorisation.
Avec des flux OAuth2 classiques, les clients demandent généralement l’accès à un ensemble de permissions à un serveur de ressources, et le propriétaire des ressources accorde l’accès à ces ressources aux clients. Toutefois, cette approche ne permet pas un contrôle granulaire de l’accès accordé à un client et peut conduire à un excès de fourniture d’accès, ce qui peut présenter des risques pour la sécurité.
Avec les RAR, les clients peuvent passer un paramètre authorization_details pour demander des autorisations particulières pour chaque ressource à laquelle ils souhaitent accéder. Cela permet un contrôle plus fin de l’accès et peut contribuer à atténuer les risques de sécurité associés à l’excès de fourniture.
Dans l’ensemble, les RAR sont une extension puissante du protocole OAuth2 qui permet d’améliorer la sécurité et le contrôle de l’accès aux ressources, tant pour les clients que pour les propriétaires de ressources.
Comment les utiliser?
Après avoir configuré des RAR pour votre API, vous pouvez ajouter le paramètre authorization_details à une demande transmise au point de terminaison /par. Le paramètre est un tableau d’objets. Chaque objet doit avoir un champ de type, mais les types n’ont pas besoin d’être uniques dans le tableau. Voici un exemple utilisant le flux de code d’autorisation :
curl --location 'https://$tenant/oauth/par' \
--request POST \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'client_id=$client_id' \
--data-urlencode 'client_secret=$client_secret' \
--data-urlencode 'redirect_uri=https://jwt.io' \
--data-urlencode 'audience=urn:my-api' \
--data-urlencode 'response_type=code' \
--data-urlencode 'authorization_details=[{"type": "money_transfer", "instructedAmount": {"amount": 2500, "currency": "USD"}, "sourceAccount": "xxxxxxxxxxx1234", "destinationAccount": "xxxxxxxxxxx9876", "beneficiary": "Hanna Herwitz", "subject": "A Lannister Always Pays His Debts"}]'Was this helpful?
Afin de protéger les données sensibles dans le canal frontal (c’est-à-dire le navigateur) et d’effectuer une validation anticipée des types reçus, Auth0 ne vous permet pas d’ajouter authorization_details directement sur le point de terminaison /authorize. Vous devez les transmettre au point de terminaison /par, puis utiliser le flux Code d’autorisation, comme expliqué dans Flux Code d’autorisation avec les demandes d’autorisation push.
Chaque élément authorization_details peut être entièrement personnalisé tant qu’il contient un champ type.
Lorsque vous échangez votre code d’autorisation au point de terminaison /oauth/token, comme l’illustre l’exemple de code suivant :
POST https://$tenant/oauth/token
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&client_id=[CLIENT_ID]&client_secret=[CLIENT_SECRET]&code=[AUTHZ_CODE]&redirect_uri=https://jwt.ioWas this helpful?
Vous recevez une réponse contenant le jeton d’accès et le tableau authorization_details :
{
"access_token": "ey...ZQ",
"expires_in": 86400,
"authorization_details": [
{
"type": "money_transfer",
"instructedAmount": {"amount": 2500, "currency": "USD"},
"sourceAccount": "xxxxxxxxxxx1234",
"destinationAccount": "xxxxxxxxxxx9876",
"beneficiary": "Hanna Herwitz",
"subject": "A Lannister Always Pays His Debts"
}
],
"token_type": "Bearer"
}Was this helpful?
Le tableau authorization_details aide le client à comprendre la permission de l’autorisation qui lui a été accordée sans avoir à inspecter le jeton d’accès. En général, le client ne devrait jamais inspecter le jeton d’accès, ce qui est détaillé dans le profil de jeton Web JSON d’IETF pour les jetons d’accès OAuth 2.0. C’est plutôt le serveur de ressources qui doit inspecter le jeton d’accès.
Si l'audience demandée est une API configurée pour utiliser des jetons d’accès JWE, tous les champs à l’exception de type seront supprimés des éléments authorization_details dans la réponse du point de terminaison /oauth/token. Les demandes de jetons d’accès ne sont pas affectées.
{
"iss": "https://my_tenant.auth0.com/",
"sub": "auth0|me",
"aud": "https://myapi.authzero.com",
"iat": 1683661385,
"exp": 1683747785,
"azp": "my_client",
"authorization_details": [
{
"type": "money_transfer",
"instructedAmount": {"amount": 2500, "currency": "USD"},
"sourceAccount": "xxxxxxxxxxx1234",
"destinationAccount": "xxxxxxxxxxx9876",
"beneficiary": "Hanna Herwitz",
"subject": "A Lannister Always Pays His Debts"
}
]
}Was this helpful?
Accéder aux authorization_details dans les actions
En plus de la prise en charge du protocole standard, nous exposons également les RAR dans l’action post-connexion via la propriété event.transaction.requested_authorization_details. Utilisez cette propriété pour prendre des décisions concernant la transaction, notamment pour appliquer l’authentification multifacteur (MFA).
Auth0 ne permet pas actuellement de mettre à jour RAR à l’aide d’Actions.
Qu’est-ce qu’Auth0 ne prend pas en charge?
À ce stade, Auth0 ne prend pas en charge ce qui suit :
la mise à jour des RAR dans les actions;
la publicité des types de RAR pour les faire découvrir aux clients.
Validez les objets RAR en vérifiant qu’ils possèdent une propriété type correspondant aux types autorisés pour l’API. Pour en savoir plus, consultez Configurer les RAR.