- Primeros pasos
- Autenticación
- Métodos de autenticación
- Aplicaciones externas (OAuth)
- ROPC (no recomendado)
- Definición de Swagger
- API de Orchestrator
- Solicitudes de alertas
- Solicitudes de activos
- Solicitudes de calendario
- Solicitudes de entornos
- Solicitudes de carpetas
- Solicitudes de tareas genéricas
- Solicitudes de trabajos
- Solicitudes de bibliotecas
- Solicitudes de licencia
- Solicitudes de paquetes
- Solicitudes de permisos
- Solicitudes de espacios de trabajo personales
- Solicitudes de procesos
- Solicitudes de elementos en cola
- Solicitudes de robots
- Solicitudes de roles
- Solicitudes de horarios
- Solicitudes de configuración
- Solicitudes de tareas
- Solicitudes de catálogos de tareas
- Solicitudes de formularios de tareas
- Solicitudes de tenants
- Solicitudes de transacciones
- Solicitudes de usuario
- Solicitudes de Webhooks
- API de gestión de plataformas
Aplicaciones externas (OAuth)
Como desarrollador que trabaja en la integración de productos UiPath con aplicaciones externas, eres responsable de tareas como la gestión de cambios de ámbito, la gestión de tokens de acceso y tokens de actualización y el mantenimiento de la integración entre la aplicación externa y los recursos de UiPath. La siguiente guía te orienta a través de estas operaciones.
OAuth ofrece una selección de bibliotecas que puedes aprovechar para simplificar la autenticación, la autorización, la delegación y la seguridad de las llamadas a la API. Puedes acceder a estos recursos directamente desde el sitio web oficial de OAuth.
Como desarrollador, una vez que el administrador de la organización haya registrado tu aplicación externa en UiPath, deberás obtener los detalles de registro para autenticar tu aplicación externa con recursos de UiPath.
-
El tipo de aplicación y el ID de aplicación. Si trabajas con una aplicación confidencial, también necesitarás el Secreto de la aplicación. Estos se utilizan para autenticar tu aplicación con Identity Server de UiPath, el servidor de autorización para acceder a los recursos de UiPath, que admite el marco OAuth 2.0.
-
Además, debes conocer los ámbitos de la aplicación externa, que definen a qué recursos puede acceder tu aplicación externa en UiPath. Esto incluye tanto la especificación del recurso (como activos, procesos, etc.) como el nivel de permiso (lectura, escritura, edición, etc.).
Una vez registrada la aplicación externa, debes implementar el mecanismo de autorización adecuado para la aplicación externa con el tipo de concesión adecuado para que la aplicación externa pueda recuperar un token de acceso.
Durante este proceso, solicita un token de acceso proporcionando el ámbito de la aplicación externa y las credenciales de la aplicación registrada (el ID de la aplicación (y el Secreto de la aplicación en el caso de las aplicaciones confidenciales)) a Identity Server. Si las credenciales son válidas, Identity Server responde emitiendo un código de autorización, que se utilizará para generar el token de acceso.
Tipo de aplicación |
Ámbito |
Tipo de concesión requerida |
---|---|---|
Confidencial |
Aplicación |
Credenciales de Cliente |
Confidencial |
Usuario |
Código de autorización |
Confidencial |
aplicación y usuario |
Credenciales de cliente y código de autorización |
no confidenciales |
Usuario |
Código de autorización con PKCE |
Cuando el nombre del ámbito es el mismo tanto en el ámbito de usuario como en el de aplicación, como en el caso de Orchestrator, el tipo de concesión que se utiliza determina si el recurso se llama en el ámbito de usuario o en el de aplicación.
El ámbito definido por el administrador para una aplicación determina el nivel máximo de acceso que la aplicación puede alcanzar. Como desarrollador, si solicitas acceso más allá de este ámbito predefinido, tu solicitud falla. Por lo tanto, es importante asegurarse de que tus solicitudes estén dentro del ámbito definido por el administrador.
En el nivel de administrador, los permisos de la aplicación pueden ser:
-
Permisos de ámbito de la organización: de forma predeterminada, cuando se registra una aplicación externa, tiene acceso de toda la organización a los recursos según los ámbitos establecidos.
-
Permisos detallados: para una configuración de permisos más granular, el administrador de la organización puede asignar un rol a nivel de tenant o carpeta dentro de Orchestrator a la aplicación externa, aunque esto solo es aplicable a aplicaciones confidenciales.
En el nivel de desarrollador, la declaración de ámbitos se realiza de la siguiente manera:
-
Permisos de ámbito de la organización: al declarar un ámbito especificado explícitamente como
OR.Machines.View
en la solicitud de token, implica que la aplicación solicita un permiso de acceso para toda la organización. -
Permisos detallados: para proporcionar a tu aplicación un acceso detallado, debes declarar
OR.Default
en la solicitud del token.OR.Default
actúa como un ámbito de comodín, proporcionando a tu aplicación un acceso detallado que depende de su rol asignado en tenants o carpetas específicas.
OR.Machines.View
y OR.Default
. Esta declaración combinada permite que tu aplicación externa funcione tanto en el nivel de organización como en tenants o carpetas específicas de Orchestrator.
Comprueba el punto final en la documentación de API del recurso para obtener los valores de ámbito que necesitas. Por ejemplo:
Con este tipo de concesión, el flujo es el siguiente:
-
La aplicación externa solicita un token de acceso enviando una solicitud POST que incluye
client_id
yclient_secret
al punto final del token de 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}Campo
Descripción
client_id
Especifica el identificador único asignado a la aplicación durante su registro.
Debe contener el ID de la aplicación (proporcionado por el administrador).
client_secret
Especifica información confidencial, como una contraseña, que se proporciona a las aplicaciones confidenciales en el momento de su registro. Este campo se utiliza junto con elclient_id
para autenticar la aplicación cuando emite solicitudes al Identity Server.Debe contener el secreto de la aplicación (proporcionado por el administrador).
scope
Especifica los ámbitos solicitados por la aplicación, delimitados por un espacio; por ejemplo:OR.Machines.View OR.Default
.-
Usa
OR.Default
para conceder acceso controlado y personalizado dentro de tenants o carpetas específicas. Los permisos reales que obtiene la aplicación se determinan en función de dónde se asigna la aplicación dentro de los tenants o carpetas por el administrador. -
Utiliza ámbitos explícitos como
OR.Machines.View
para conceder acceso amplio en toda la organización a ciertos recursos.
-
-
La aplicación externa recibe una respuesta que contiene el token de acceso:La aplicación puede utilizar el token de acceso para acceder a los recursos del usuario hasta que el token caduque (una hora).
{ "access_token":"{access_token}", "expires_in":3600, "token_type":"Bearer", "scope":"{scopes}" }
{ "access_token":"{access_token}", "expires_in":3600, "token_type":"Bearer", "scope":"{scopes}" }
Para obtener una comprensión detallada del flujo OAuth que utiliza códigos de autorización, consulta el documento RFC 6749.
application/x-www-form-urlencoded
La aplicación puede utilizar el token de acceso para acceder a los recursos del usuario hasta que el token caduque (una hora).
Para una aplicación no confidencial con ámbitos de usuario, realizas el código de autorización con el flujo PKCE. Para obtener una comprensión detallada del flujo OAuth que utiliza código de autorización con PKCE, consulta el documento RFC 7636.
Con este tipo de concesión, el flujo es el siguiente:
-
La aplicación externa envía una solicitud de autorización para obtener el código de autorización al punto final
https://{yourDomain}/identity/connect/authorize?
: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=S256Opción
Descripción
client_id
Especifica el identificador único asignado a la aplicación durante su registro.
Debe contener el ID de la aplicación (como lo proporciona el administrador).
scope
Especifica los ámbitos solicitados por la aplicación, delimitados por un espacio; por ejemplo:OR.Machines.View
.redirect_uri
Especifica la URL donde UiPath Identity Server redirecciona la solicitud de autorización después de que se haya concedido el código de autorización.
code_challenge_method
Especifica el método utilizado para codificarcode_verifier
para elcode_challenge
. El valor para este campo debe ser S256, lo que significa quecode_verifier
debe ser hash utilizando SHA256 y codificado en base64url para crear elcode_challenge
.code_challenge
Una cadena criptográficamente aleatoria derivada decode_verifier
, utilizada para conectar la solicitud de autorización a la solicitud de token.Debe utilizar un algoritmo verificador de código para generar el desafío de código. También puedes crear el tuyo propio, siempre que cumpla con el estándar rfc7636.
-
En la solicitud de token POST a
https://{identity_baseURL}/connect/token
, es necesario incluircode_verifier
(la cadena original utilizada para generarcode_challenge
) en el cuerpo de la solicitud.La respuesta incluye un token de acceso que la aplicación puede utilizar para acceder a los recursos del usuario hasta que el token caduque (una hora).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}
Cuando la aplicación tiene un token de acceso, puede utilizarse para acceder a los recursos permitidos, limitados a los ámbitos seleccionados, hasta que el token caduque (una hora).
odata/Machines
que utiliza un token de acceso en el encabezado de Autorización, donde el token de acceso contiene ámbito OR.Machines
en la reclamación de ámbito.
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"
Los tokens de acceso caducan en una hora. La aplicación externa puede obtener un nuevo token de acceso sin la interacción del usuario intercambiando un token de actualización por él. Tanto las aplicaciones externas confidenciales como las no confidenciales pueden solicitar un token de actualización. Sin embargo, el flujo de credenciales de cliente no admite tokens de actualización. En el flujo de credenciales de cliente, los tokens de acceso se conceden directamente sin tokens de actualización. Cuando los clientes necesitan un nuevo token, deben volver a autenticarse utilizando sus credenciales.
Los tokens de actualización también son válidos para un solo uso y caducan a los 60 días.
offline_access
en el parámetro scope
de la solicitud de autorización para que el código de autorización pueda usarse en una solicitud de token para obtener un token de actualización.
Envía una petición POST con el código de autorización al punto de conexión del token
https://{yourDomain}/identity/connect/token
.
application/x-www-form-urlencoded
.
La solicitud devuelve un nuevo token de acceso y un token de actualización:
{
"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
utilizando el tipo de concesión 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
del cuerpo de la solicitud.
La respuesta devuelve un nuevo token de acceso y un nuevo token de actualización.
El token de actualización existente ya no es válido después de su uso, así que asegúrate de utilizar el nuevo token de actualización que has recibido.
application/x-www-form-urlencoded
para cualquier petición a los puntos de conexión del Identity Server. Esto no es necesario si las solicitudes se realizan de forma programada.
Capa de servidor de identidad | PuntoFinal | Descripción |
---|---|---|
Discovery | https://{yourDomain}/identity/.well-known/openid-configuration | Usa este punto final para recuperar metadatos sobre tu instancia de Identity Server. |
Autorización | https://{yourDomain}/identity/connect/authorize | Utilice este punto final para solicitar tokens o códigos de autorización a través del navegador. Este proceso incluye la autenticación del usuario final y, de forma opcional, el consentimiento. |
Token | https://{yourDomain}/identity/connect/token | Usa este extremo para solicitar tokens mediante programación.
Ten en cuenta que para este punto final, el tipo de contenido debe ser
application/x-www-form-urlencoded .
|
- Requisitos previos
- Autenticar y autorizar aplicaciones externas
- Qué tipo de concesión de autorización utilizar
- Declarar ámbitos
- Aplicaciones confidenciales con ámbitos de aplicación (flujo de credenciales de cliente)
- Aplicaciones confidenciales con ámbitos de usuario (flujo de código de autorización)
- Aplicaciones no confidenciales con ámbitos de usuario (código de autorización con flujo PKCE)
- Uso del token de acceso
- Obtener un token de actualización
- Obtener un token de actualización
- Obtener un nuevo token de actualización y un nuevo token de acceso
- Puntos finales de UiPath® Identity Server