- Démarrage
- Authentification
- Méthodes d'authentification SQL
- Applications externes (OAuth)
- ROPC (non recommandé)
- Définition Swagger
- API Orchestrator
- Demandes d'alertes
- Requêtes relatives aux actifs
- Requêtes de calendriers
- Requêtes relatives aux environnements
- Requêtes de dossiers
- Requêtes de tâches génériques
- Requêtes relatives aux tâches
- Requêtes relatives aux bibliothèques
- Requêtes relatives aux licences
- Requêtes relatives aux paquets (Packages Requests)
- Requêtes relatives aux autorisations
- Demandes d'espaces de travail personnels
- Requêtes relatives aux processus
- Demandes d'éléments de la file d'attente
- Requêtes relatives aux Robots
- Requêtes relatives aux rôles (Roles Requests)
- Requêtes relatives aux planifications
- Requêtes relatives aux paramètres
- Requêtes de tâches
- Demandes de catalogues de tâches
- Demandes de formulaires de tâches
- Requêtes relatives aux locataires
- Requêtes relatives aux transactions
- Requêtes relatives aux utilisateurs
- Requêtes relatives aux Webhooks
- API de gestion de plate-forme
![](https://docs.uipath.com/_next/static/media/grid.05ebd128.png?w=3840&%3Bq=100)
Applications externes (OAuth)
En tant que développeur travaillant sur l’intégration des produits UiPath avec des applications externes, vous êtes responsable de tâches telles que la gestion des modifications d’étendue, la gestion des jetons d’accès et des jetons de réactualisation, ainsi que la maintenance de l’intégration entre l’application externe et les ressources UiPath. Le guide suivant vous détaille l’ensemble de ces opérations.
OAuth propose une sélection de bibliothèques que vous pouvez exploiter pour simplifier l’authentification, l’autorisation, la délégation et la sécurisation des appels d’API. Vous pouvez accéder à ces ressources directement sur le site Web officiel d’OAuth.
En tant que développeur, une fois que l’administrateur de l’organisation a enregistré votre application externe dans UiPath, vous devriez obtenir les détails d’enregistrement vous permettant d’authentifier votre application externe avec les ressources UiPath.
-
Le Type d’application et l’ID d’application. Si vous travaillez avec une application confidentielle, vous aurez également besoin de la clé secrète de l’application. Cette clé sert à authentifier votre application auprès de UiPath Identity Server, le serveur d’autorisation permettant d’accéder aux ressources UiPath, lequel prend en charge l’infrastructure OAuth 2.0.
-
De plus, vous devez connaître les étendues de l’application externe, qui définissent les ressources auxquelles votre application externe pourra accéder dans UiPath. Cela inclut à la fois la spécification des ressources (comme ressources, processus, etc.) et le niveau d’autorisation (lecture, écriture, modification, etc.).
Une fois l’application externe enregistrée, vous devez implémenter le mécanisme d’autorisation approprié pour l’application externe, avec le type d’accord approprié, afin que l’application externe puisse récupérer un jeton d’accès.
Au cours de ce processus, demandez un jeton d’accès en fournissant à Identity Server l’étendue de l’application externe ainsi que les informations d’identification de l’application enregistrée, soit l’ID de l’application, ainsi que la clé secrète de l’application dans le cas d’applications confidentielles. Si les informations d’identification sont valides, Identity Server répond en émettant un code d’autorisation, qui sera utilisé pour générer le jeton d’accès.
Type de demande (Application Type) |
Portée |
Type d'accord requis |
---|---|---|
confidentiel |
Application |
Informations d’identification du client |
confidentiel |
Utilisateur (User) |
Code d'autorisation |
confidentiel |
application et utilisateur |
Informations d’identification du client et code d’autorisation |
non confidentiel |
Utilisateur (User) |
Code d'autorisation avec PKCE |
Lorsque le nom de l'étendue est le même dans l'étendue de l'utilisateur et de l'application, comme dans le cas d'Orchestrator, le type d'octroi que vous utilisez détermine si la ressource est appelée dans l'étendue de l'utilisateur ou dans l'étendue de l'application.
L’étendue définie par l’administrateur pour une application détermine le niveau d’accès maximum que l’application peut atteindre. En tant que développeur, si vous demandez un accès supérieur à cette étendue prédéfinie, votre demande échouera. Par conséquent, il est important de veiller à ce que vos demandes respectent l’étendue définie par l’administrateur.
Au niveau de l’administrateur, les autorisations de l’application peuvent être les suivantes :
-
Autorisations à l’échelle de l’organisation : par défaut, lorsqu’une application externe est enregistrée, l’accès aux ressources est accordé à l’ensemble de l’organisation, en fonction des étendues définies.
-
Autorisations affinées : pour des paramètres d’autorisation plus précis, l’administrateur de l’organisation peut attribuer à l’application externe un rôle au niveau du locataire ou du dossier dans Orchestrator, bien que cela soit uniquement possible pour les applications confidentielles.
Au niveau du développeur, la déclaration des étendues s’effectue comme suit :
-
Autorisations à l’échelle de l’organisation : lorsque vous déclarez une étendue explicitement spécifiée dans la demande de jeton, telle que
OR.Machines.View
, cela implique que l’application demande une autorisation d’accès à l’échelle de l’organisation. -
Autorisations affinées : afin de fournir à votre application des accès affinés, vous devez déclarer
OR.Default
dans la demande de jeton.OR.Default
agit comme une étendue de caractère générique, en fournissant à votre application un accès précis qui dépendra du rôle lui étant attribué dans des locataires ou des dossiers spécifiques.
OR.Machines.View
et OR.Default
. Cette déclaration combinée permet à votre application externe de fonctionner à l’échelle de toute l’organisation, ainsi qu’à l’échelle de locataires ou de dossiers Orchestrator spécifiques.
Vérifiez le point de terminaison dans la documentation de l’API de la ressource pour obtenir les valeurs d’étendue dont vous avez besoin. Par exemple :
Applications confidentielles avec étendues d’application (flux d’informations d’identification du client)
Avec ce type d'accord, le flux est le suivant :
-
L’application externe demande un jeton d’accès en envoyant une demande POST qui inclut le
client_id
et leclient_secret
au point de terminaison du jeton Identity Server :
:https://{yourDomain}/identity
/connect/tokengrant_type=client_credentials&client_id={app_id}&client_secret={app_secret}&scope={scopes}
grant_type=client_credentials&client_id={app_id}&client_secret={app_secret}&scope={scopes}Champ
Description
client_id
Spécifie l’identifiant unique attribué à l’application lors de son enregistrement.
Doit contenir l’ID de l’application (fourni par l’administrateur).
client_secret
Spécifie des informations confidentielles telles qu’un mot de passe, lesquelles seront fournies aux applications confidentielles lors de leur enregistrement. Ce champ est utilisé avecclient_id
pour authentifier l’application lorsque celle-ci envoie des requêtes à Identity Server.Doit contenir la clé secrète de l’application (fournie par l’administrateur).
scope
Spécifie les étendues demandées par l’application, délimitées par un espace ; par exemple :OR.Machines.View OR.Default
.-
Utilisez
OR.Default
pour accorder un accès contrôlé et personnalisé à des locataires ou des dossiers spécifiques. Les autorisations réelles obtenues par l’application sont déterminées en fonction de l’emplacement où l’application a été attribuée par l’administrateur (locataires ou dossiers). -
Utilisez des étendues explicites telles que
OR.Machines.View
afin d’accorder un accès étendu à certaines ressources à l’échelle de l’organisation.
-
-
L’application externe reçoit une réponse contenant le jeton d’accès :L’application peut utiliser le jeton d’accès pour accéder aux ressources utilisateur jusqu’à l’expiration du jeton (une heure).
{ "access_token":"{access_token}", "expires_in":3600, "token_type":"Bearer", "scope":"{scopes}" }
{ "access_token":"{access_token}", "expires_in":3600, "token_type":"Bearer", "scope":"{scopes}" }
Pour une présentation détaillée du flux OAuth utilisant des codes d’autorisation, reportez-vous au document RFC 6749.
application/x-www-form-urlencoded
L’application peut utiliser le jeton d’accès pour accéder aux ressources utilisateur jusqu’à l’expiration du jeton (une heure).
Applications non confidentielles avec des étendues d’utilisateur (code d’autorisation avec flux PKCE)
Pour une application non confidentielle avec des étendues d’utilisateur, le code d’autorisation s’exécute avec le flux PKCE. Pour une présentation détaillée du flux OAuth utilisant le code d’autorisation PKCE, reportez-vous au document RFC 7636.
Avec ce type d'accord, le flux est le suivant :
-
L’application externe envoie une demande d’autorisation au point de terminaison
https://{yourDomain}/identity/connect/authorize?
afin d’obtenir le code d’autorisation :response_type=code&client_id={app_id}&scope={scopes}&redirect_uri={redirect_url}&code_challenge={cryptographically-random string from code_verifier}&code_challenge_method=S256
response_type=code&client_id={app_id}&scope={scopes}&redirect_uri={redirect_url}&code_challenge={cryptographically-random string from code_verifier}&code_challenge_method=S256Option
Description
client_id
Spécifie l’identifiant unique attribué à l’application lors de son enregistrement.
Doit contenir l’ID de l’application (tel que fourni par l’administrateur).
scope
Spécifie les étendues demandées par l’application, délimitées par un espace ; par exemple :OR.Machines.View
.redirect_uri
Spécifie l’URL vers laquelle UiPath Identity Server redirige la demande d’autorisation une fois le code d’autorisation accordé.
code_challenge_method
Spécifie la méthode utilisée pour encoder lecode_verifier
ducode_challenge
. La valeur de ce champ doit être S256, ce qui signifie que lecode_verifier
doit être haché via SHA256 et via un encodage base64url pour créer lecode_challenge
.code_challenge
Une chaîne de caractères à la cryptographie aléatoire dérivée decode_verifier
, utilisée pour connecter la demande d’autorisation à la demande de jeton.Vous devez utiliser un algorithme de vérification de code pour générer le défi de code. Vous pouvez également créer le vôtre, à condition qu'il soit conforme à la norme rfc7636.
-
Dans la demande de jeton POST à
https://{identity_baseURL}/connect/token
, vous devez inclurecode_verifier
(la chaîne d'origine utilisée pour générercode_challenge
) dans le corps de la demande.La réponse comprend un jeton d'accès que l'application peut utiliser pour accéder aux ressources utilisateur jusqu'à l'expiration du jeton (une heure).grant_type=authorization_code&code={authorization_code}&redirect_uri={redirect_url}&client_id={app_id}&code_verifier={code_verifier}
grant_type=authorization_code&code={authorization_code}&redirect_uri={redirect_url}&client_id={app_id}&code_verifier={code_verifier}
Une fois que l'application dispose d'un jeton d'accès, elle peut utiliser le jeton pour accéder aux ressources autorisées, limitées aux étendues sélectionnées, jusqu'à l'expiration du jeton (une heure).
odata/Machines
qui utilise un jeton d’accès dans l’en-tête d’autorisation, où le jeton d’accès contient l’étendue OR.Machines
dans la demande d’étendue.
curl -X GET "https://{yourDomain}/odata/Machines"
-H "Authorization: Bearer {access_token}" -H "accept: application/json"
curl -X GET "https://{yourDomain}/odata/Machines"
-H "Authorization: Bearer {access_token}" -H "accept: application/json"
Les jetons d’accès ont un délai d’expiration d’une heure. L’application externe peut obtenir un nouveau jeton d’accès, sans interaction de l’utilisateur, en le remplaçant par un jeton de réactualisation. Les applications externes confidentielles et non confidentielles peuvent toutes deux demander un jeton d’actualisation. Le flux d’informations d’identification du client ne prend cependant pas en charge les jetons de réactualisation. Dans le flux d’informations d’identification du client, les jetons d’accès sont délivrés directement sans passer par un jeton de réactualisation. Lorsque les clients ont besoin d’un nouveau jeton, ils doivent procéder à une nouvelle authentification à l’aide de leurs informations d’identification.
Les jetons de réactualisation sont également valables pour une seule utilisation et ils expirent après 60 jours.
offline_access
dans le paramètre scope
de la demande d'autorisation afin que le code d'autorisation puisse être utilisé dans une demande de jeton afin d'obtenir un jeton de réactualisation.
Envoyer une requête POST avec le code d'autorisation au point de terminaison du jeton
https://{yourDomain}/identity/connect/token
.
application/x-www-form-urlencoded
.
La requête renvoie un nouveau jeton d'accès et un jeton de réactualisation :
{
"access_token": "{access_token}",
"expires_in": 3600,
"token_type": "Bearer",
"refresh_token": "{refresh_token}",
"scope": "OR.Machines OR.Robots offline_access"
}
{
"access_token": "{access_token}",
"expires_in": 3600,
"token_type": "Bearer",
"refresh_token": "{refresh_token}",
"scope": "OR.Machines OR.Robots offline_access"
}
https://{yourDomain}/identity/connect/token
à l'aide du type d'accord refresh_token
.
application/x-www-form-urlencoded
.
{
"grant_type": "refresh_token",
"client_id": "{app_id}",
"client_secret": "{app_secret}",
"refresh_token": "{existing_refresh_token}"
}
{
"grant_type": "refresh_token",
"client_id": "{app_id}",
"client_secret": "{app_secret}",
"refresh_token": "{existing_refresh_token}"
}
client_secret
du corps de la demande.
La réponse renvoie un nouveau jeton d'accès et un nouveau jeton de réactualisation.
Le jeton de réactualisation existant n'est plus valide après utilisation, alors assurez-vous d'utiliser le nouveau jeton de réactualisation que vous avez reçu.
application/x-www-form-urlencoded
pour toutes les demandes faites aux points de terminaison d'Identity Server. Si vous effectuez des demandes par programmation, cela n'est pas nécessaire.
Couche Identity Server | Endpoint | Description |
---|---|---|
Découverte | https://{yourDomain}/identity/.well-known/openid-configuration | Utilisez ce point de terminaison pour récupérer des métadonnées sur votre instance d'Identity Server. |
Autorisation | https://{yourDomain}/identity/connect/authorize | Utilisez ce point de terminaison pour demander des jetons ou des codes d'autorisation via le navigateur. Ce processus comprend l'authentification de l'utilisateur final et éventuellement le consentement. |
Jeton | https://{yourDomain}/identity/connect/token | Utilisez ce point de terminaison pour demander des jetons par programmation.
Veuillez noter que pour ce point de terminaison, le type de contenu doit être
application/x-www-form-urlencoded .
|
- Prérequis
- Authentifier et autoriser des applications externes
- Quel type d’accord d’autorisation utiliser ?
- Déclarer les étendues
- Applications confidentielles avec étendues d’application (flux d’informations d’identification du client)
- Applications confidentielles avec étendues d’utilisateur (flux de code d’autorisation)
- Applications non confidentielles avec des étendues d’utilisateur (code d’autorisation avec flux PKCE)
- Utilisation du jeton d'accès
- Obtention d'un jeton de réactualisation
- Obtenir un jeton d'actualisation
- Obtenir un nouveau jeton de réactualisation et un nouveau jeton d'accès
- Points de terminaison du serveur d’identité UiPath®