OAuth 2.0-basierte Authentifizierung für Clientanwendungen verwenden

Open Authorization (OAuth) 2.0 beschreibt mehrere Wege für einen Ressourceneigner, Zugriff auf seine geschützten Ressourcen zu gewähren. IBM® Cloud Pak for Business Automation as a Service unterstützt nur den ROPC-Gewährungstyp (Resource Owner Password Credentials) für die Authentifizierung des Zugriffs von Client-Anwendungen auf die Cloud-Umgebung.

Anmerkung: Die OAuth 2.0 -basierte Authentifizierung ist in Cloudsubskriptionen standardmäßig nicht aktiviert. Wenn Sie es verwenden möchten, senden Sie eine Anfrage über das Support-Portal IBM.

ROPC-Grant-Typ

In OAuth 2.0 sind Cloud Pak for Business Automation as a Service -Clientanwendungen vertrauliche Clients. Für den ROPC-Grant-Typ erfordern sie einen Satz von Clientberechtigungsnachweisen (bestehend aus einer Client-ID und einem geheimen Clientschlüssel) sowie den Benutzernamen und das Kennwort eines Ressourceneigners. Verwenden Sie zum Abrufen der Clientberechtigungsnachweise die API Credentials , um sie zu generieren. Melden Sie sich für den Benutzernamen und das Kennwort im Cloudportal als Kontoadministrator an, generieren Sie einen Satz Serviceberechtigungsnachweise und ordnen Sie sie den Berechtigungen zu, die für die Clientanwendung erforderlich sind. Die Berechtigungen werden verwendet, um OAuth 2.0-tokenbasierten Zugriff auf die Cloudumgebungen zu steuern.

Weitere Informationen zu OAuth und dem ROPC-Zuschusstyp finden Sie im OAuth 2.0 Authorization Framework. Informationen zur Credentials -API finden Sie unter Beispiel: Anmeldeinformationen REST-API für OAuth 2.0 -basierte Authentifizierung und zum Abrufen von Dienstanmeldeinformationen unter Erstellen und Verwalten von Dienstkonten.

OAuth 2.0-Clientberechtigungsnachweise verwalten

OAuth 2.0-Clients müssen Clientberechtigungsnachweise bereitstellen, um den aufrufenden Clientkontext zu identifizieren. Sie entscheiden, wie viele Sätze von Berechtigungsnachweisen Sie benötigen. Sie können beispielsweise einen Satz für alle OAuth 2.0-Clients verwenden oder über einen separaten Satz von Berechtigungsnachweisen für jeden Client verfügen.

Um die OAuth 2.0-Authentifizierung in Ihrer Clientanwendung zu verwenden, muss Ihre Anwendung die folgenden Interaktionen enthalten.

Wichtig: Die folgenden Aufrufe geben möglicherweise einen Set-Cookie-Befehl für die Cookies PD-S-SESSION-ID und PD-ID als Teil der Antwort zurück. Verwenden Sie diese Cookies nicht bei nachfolgenden Aufrufen.

Abrufen eines OAuth 2.0-Zugriffstokens.
Verwenden Sie den OAuth 2.0-Endpunkt /token, um ein Zugriffstoken, einschließlich Client (Client-ID und geheimer Clientschlüssel) und Serviceberechtigungsnachweise (Benutzername und Kennwort), anzufordern. Beispiel:
```
curl -k -v -X POST -H 'content-type: application/x-www-form-urlencoded' 
-d grant_type=password -d client_id=<clientId> -d client_secret=<clientSecret>
-d username=<serviceCredId> -d password=<svcCredSecret>
https://www.bpm.ibmcloud.com/mga/sps/oauth/oauth20/token
```
Der Aufruf gibt das in nachfolgenden Cloudoperations-API-Aufrufen zu verwendende Zugriffstoken, ein Aktualisierungstoken zum Aktualisieren des Zugriffstokens und eine Ablaufdauer für das Zugriffstoken zurück. Denken Sie daran, dass Zugriffstoken üblicherweise für Minuten oder Stunden gültig sind, während Aktualisierungstoken mehrere Tage gültig sein können. Scoping wird nicht unterstützt.
```
{"access_token":"CJ7yDymDAfSRz03W7zdX","refresh_token":"fGAv2qzuLnM030Brs8KFaIuY1Kd2P87sLFXI85lH","scope":"","token_type":"bearer","expires_in":1799}*
```
Wenn der Aufruf erfolgreich ist, wird der HTTP-Antwortcode 201 zurückgegeben. Wenn die Client- oder Serviceberechtigungsnachweise ungültig sind, gibt der Aufruf den HTTP-Antwortcode BAD_REQUEST (400)zurück.
Verwenden Sie das Token, um auf die Cloudoperations-APIs zuzugreifen.
Schließen Sie das zurückgegebene Zugriffstoken aus dem vorherigen Schritt in den Berechtigungsheader des Cloudoperations-API-Aufrufs ein. Beispiel:
```
curl -k -v -H "Authorization: Bearer CJ7yDymDAfSRz03W7zdX" https://<tenantHost>/baw/dev/rest/bpm/wle/v1/user/current
```
Wenn das Zugriffstoken ungültig oder abgelaufen ist, gibt der Aufruf den HTTP-Antwortcode 302 zurück.

Aktualisieren Sie das Zugriffstoken mithilfe eines Aktualisierungstokens.

Verwenden Sie den OAuth 2.0-Endpunkt /token.

curl -k -v -X POST -H 'content-type: application/x-www-form-urlencoded' 
-d grant_type=refresh_token -d refresh_token=fGU3UjAHG0XKTdnInU8ihqTLf48XJIzQtRUjNFVo
-d client_id=<clientId> -d client_secret=<clientSecret>
https://www.bpm.ibmcloud.com/mga/sps/oauth/oauth20/token

Der Aufruf gibt einen neuen Satz von Tokens zurück.

{"access_token":"DkhN7gg7mk2gsBjGi8ay","refresh_token":"ToY13V2yfoYaeVbBjTwFLhzwX7GiKd7Y801VfjGC","scope":"","token_type":"bearer","expires_in":1799}

Der Aufruf gibt den HTTP-Antwortcode BAD_REQUEST (400) zurück, wenn das Aktualisierungstoken ungültig ist oder bereits verwendet wurde oder wenn die Clientberechtigungsnachweise ungültig sind, beispielsweise weil sie gelöscht wurden.

Widerrufen Sie das Aktualisierungs- und Zugriffstoken nach Abschluss der Verarbeitung der Clientanwendung.
Wenn die Verarbeitung der Clientanwendung abgeschlossen ist, wird empfohlen, beide Tokens mithilfe des OAuth 2.0-Endpunkts /revoke zu widerrufen. Widerrufen Sie zuerst das Aktualisierungstoken, bevor Sie das Zugriffstoken widerrufen.
Verwenden Sie beispielsweise den folgenden Aufruf, um das Aktualisierungstoken zu widerrufen:
```
curl -k -v -X POST -H 'content-type: application/x-www-form-urlencoded' 
-d client_id=<clientId> -d client_secret=<clientSecret>
-d token=ToY13V2yfoYaeVbBjTwFLhzwX7GiKd7Y801VfjGC
https://www.bpm.ibmcloud.com/mga/sps/oauth/oauth20/revoke
```
Der Aufruf gibt immer einen erfolgreichen HTTP-Antwortcode zurück, z. B. 200.
Achtung: Nach dem Zugriff auf eine API bleibt das Zugriffstoken gültig, bis es abläuft.

Beschränkungen

Es gibt ein systemdefiniertes Tageslimit von mehreren Hundert gleichzeitigen gültigen Grants (Tokenpaare für Zugriff und Aktualisierung). Die Grants werden nach Clientanwendung und Benutzernamen des Ressourceneigners verfolgt. Erwartungsgemäß wird der Grenzwert für die Grants nie erreicht. Wenn jedoch eine Nachricht angezeigt wird, laut der der Grenzwert für die Grants erreicht wurde, überprüfen Sie die Konstruktion der Granterstellung in Ihrer Clientanwendung oder wenden Sie sich an den IBM Support.