- Erste Schritte
- Hier lesen
- Über OData und Referenzen
- Orchestrator-URL
- API-Referenzen
- Logische Ressourcen und Metadaten
- Verfügbare Operationen
- Aufgezählte Typen
- Authentifizierung
- Erstellen von API-Anfragen
- Zugriff auf UiPath-Ressourcen mithilfe externer Anwendungen
- Berechtigungen pro Endpunkt
- Antwortcodes
- Endpunkte zur Zustandsprüfung
- Die Swagger-Definition
- Beispiele mit der Orchestrator-API
- Warnungsanforderungen
- Anfragen zu Assets
- Kalenderanforderungen
- Umgebungsabfragen
- Ordneranforderungen
- Generische Aufgabenanforderungen
- Jobanfragen
- Bibliotheksabfragen
- Lizenzabfragen
- Paketanfragen
- Berechtigungsabfragen
- Anfragen für persönliche Arbeitsbereiche
- Prozessabfragen
- Anforderungen von Warteschlangenelementen
- Roboteranfragen
- Rollenanfragen
- Zeitplanabfragen
- Anfragen zu Einstellungen
- Aufgabenanforderungen
- Aufgabenkataloganforderungen
- Aufgabenformularanforderungen
- Mandantenabfragen
- Transaktionsanfragen
- Benutzerabfragen
- Webhook-Abfragen
- Plattformverwaltungs-APIs
Zugriff auf UiPath-Ressourcen mithilfe externer Anwendungen
Diese Anweisungen richten sich an Entwickler, die die Integration zwischen UiPath-Produkten und externen Anwendungen in einer Umgebung mit einer lokalen Orchestrator-Installation oder einer selbst gehosteten Orchestrator-Installation aufrechterhalten.
Bevor Sie beginnen:
- Die externe Anwendung muss vom Organisationsadministrator bereits in „ Externe Anwendungen “ registriert sein.
- Rufen Sie die Registrierungsdetails vom Organisationsadministrator ab.
Nachdem die externe Anwendung registriert wurde, müssen Sie den entsprechenden Autorisierungsmechanismus für die externe Anwendung mit dem entsprechenden Gewährungstyp für den zulässigen Scope implementieren, damit die externe Anwendung ein Zugriffstoken abrufen kann.
Welcher Berechtigungs-Gewährungstyp verwendet werden soll:
Anwendungstyp |
Umfang |
Erforderlicher Gewährungstyp |
---|---|---|
vertraulich |
Benutzer |
Autorisierungscode (Anweisungen) |
vertraulich |
Anwendung |
Client-Anmeldeinformationen (Anweisungen) |
nicht vertraulich |
Benutzer |
Autorisierungscode mit PKCE (Anweisungen) |
Wenn einer vertraulichen Anwendung sowohl Benutzer- als auch Anwendungs-Scopes gewährt wurden, müssen Sie beide Gewährungstypen implementieren.
Wenn der Scope-Name sowohl unter Benutzer- als auch Anwendungs-Scopes derselbe ist wie im Fall vom Orchestrator, bestimmt der von Ihnen verwendete Gewährungstyp, ob die Ressource unter dem Benutzer-Scope oder unter dem Anwendungs-Scope aufgerufen wird.
Der Autorisierungsserver für den Zugriff auf UiPath-Ressourcen ist der UiPath Identity Server, der das OAuth 2.0-Framework unterstützt.
Verwenden Sie diesen Gewährungstyp, wenn die registrierte Anwendung vom Typ vertraulich ist und die Anforderung für den Benutzer-Scope gilt.
Bei diesem Gewährungstyp ist der Ablauf wie folgt:
Jetzt kann die Anwendung das Zugriffstoken verwenden, um auf Benutzerressourcen zuzugreifen, bis das Token abläuft (eine Stunde). Weitere Informationen finden Sie unter Verwenden des Zugriffstokens und Abrufen eines Aktualisierungstokens.
Verwenden Sie diesen Gewährungstyp, wenn die registrierte Anwendung vom Typ nicht vertraulich ist und die Anforderung für den Benutzer-Scope gilt.
Der Ablauf ist derselbe wie bei der Verwendung des Autorisierungscodes: Mit Ausnahme der Autorisierungsanforderung müssen Sie die folgenden Abfrageparameter der Anforderung einschließen:
code_challenge_method
, dieS256
sein musscode_challenge
ist eine kryptografisch zufällige Zeichenfolge, die vom code_verifier abgeleitet ist und verwendet wird, um die Autorisierungsanforderung mit der Tokenanforderung zu verbinden.
Sie müssen einen Codeüberprüfungsalgorithmus verwenden, um die Codeabfrage zu generieren. Sie können auch Ihre eigene erstellen, sofern sie dem RFC7636-Standard entspricht.
{BaseURL}/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
{BaseURL}/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
{BaseURL}/identity/connect/token
müssen Sie code_verifier
(die ursprüngliche Zeichenfolge, die zum Generieren von code_challenge
verwendet wird) in den Anforderungstext aufnehmen.
application/x-www-form-urlencoded
.
{
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}"
}
Die Antwort enthält ein Zugriffstoken, das die Anwendung für den Zugriff auf Benutzerressourcen verwenden kann, bis das Token abläuft (eine Stunde). Weitere Informationen finden Sie unter Verwenden des Zugriffstokens und Abrufen eines Aktualisierungstokens.
client_id
und das client_secret
enthält, an den Identity Server-Tokenendpunkt sendet: {BaseURL}/identity/connect/token
.
application/x-www-form-urlencoded
.
{
grant_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}"
}
Sobald die Anwendung über ein Zugriffstoken verfügt, kann sie das Token verwenden, um auf zulässige Ressourcen zuzugreifen (auf die ausgewählten Scopes beschränkt), bis das Token abläuft (eine Stunde).
Dies ist eine Beispielanforderung an die odata/Machines-API, die ein Zugriffstoken im Autorisierungsheader verwendet, in dem das Zugriffstoken den Scope „OR.Maschines“ in der Scope-Anforderung enthält.
curl -X GET "{OrchestratorURL}/odata/Machines"
-H "Authorization: Bearer {access_token}" -H "accept: application/json"l
curl -X GET "{OrchestratorURL}/odata/Machines"
-H "Authorization: Bearer {access_token}" -H "accept: application/json"l
{OrchestratorURL}/swagger/index.html
.
Zugriffstoken laufen nach einer Stunde ab. Die externe Anwendung kann ein neues Zugriffstoken ohne Benutzerinteraktion erhalten, indem ein Aktualisierungstoken im Austausch dafür verwendet wird.
Aktualisierungstokens sind auch für nur eine Verwendung gültig und laufen nach 60 Tagen ab.
offline_access
in den scope
-Parameter der Autorisierungsanforderung aufnehmen, damit der Autorisierungscode in einer Tokenanforderung verwendet werden kann, um ein Aktualisierungstoken zu erhalten.
Um ein Aktualisierungstoken abzurufen, senden Sie eine POST-Anforderung mit dem Autorisierungscode an den Tokenendpunkt.
{BaseURL}/identity/connect/token
.
application/x-www-form-urlencoded
.
Die Anforderung gibt ein neues Zugriffstoken und ein Aktualisierungstoken zurück:
{
"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"
}
{BaseURL}/identity/connect/token
mit dem Gewährungstyp 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}"
}
Als Antwort wird ein neues Zugriffstoken und ein Aktualisierungstoken zurückgegeben:
Das vorhandene Aktualisierungstoken ist nach der Verwendung nicht mehr gültig, also stellen Sie sicher, dass Sie das neue Aktualisierungstoken verwenden, das Sie erhalten haben.
application/x-www-form-urlencoded
für alle Anforderungen an Identity Server-Endpunkte. Wenn Sie Anforderungen programmatisch stellen, ist dies nicht erforderlich.
{BaseURL}/identity/.well-known/openid-configuration
{BaseURL}/identity/connect/authorize
{BaseURL}/identity/connect/token