OAuth-Token und -Geltungsbereiche

Nach der Autorisierung eines Clients sendet Salesforce dem Client ein Zugriffstoken. Der Client leitet das Zugriffstoken an den Ressourcenserver weiter, um Zugriff auf geschützte Ressourcen anzufordern. Der Ressourcenserver validiert das Zugriffstoken und zusätzliche Berechtigungen in Form von Umfängen, bevor Zugriff auf den Client gewährt wird.

Das Zugriffstoken verfügt über eine längere Lebenszeit als der Autorisierungscode, normalerweise Minuten oder Stunden. Wenn ein Zugriffstoken abläuft, schlagen Versuche, es zu verwenden, fehl. Der Client muss ein neues Zugriffstoken abrufen, indem er ein Aktualisierungstoken verwendet oder den Autorisierungs-Flow erneut initiiert.

Der Client muss in der Lage sein, das Zugriffstoken vor Abfangen durch ein Protokoll wie beispielsweise Transport Layer Security (TLS oder SSL) zu schützen.

Um einen OAuth 2.0-Autorisierungsflow zu implementieren, der ein Zugriffstoken verwendet, weisen Sie der verbundenen Anwendung, die den Client in die Salesforce-API integriert, den web-Umfang zu.

Nach Erhalt eines Zugriffstokens kann der Client eine dieser Methoden verwenden, um Zugriff anzufordern.

• Verwenden Sie bei der REST-API eine HTTP-Autorisierungskopfzeile im folgenden Format: Authorization: Bearer Access_Token hinzu.
• Verwenden Sie bei der SOAP-API die SOAP-Autorisierungskopfzeile "SessionHeader". Das Zugriffstoken wird in die Kopfzeile gestellt.
• Für den Identitäts-URL müssen Sie entweder eine HTTP-Autorisierungskopfzeile (wie bei der REST-API) oder einen HTTP-Parameter vom Typ "oauth_token" verwenden.

Salesforce erteilt eindeutige Zugriffstoken für jede Kombination aus verbundener Anwendung (Client) und Benutzer. Unter den folgenden Bedingungen kann Salesforce unterschiedlichen Serviceanbietern dasselbe Zugriffstoken ausstellen:

• Sie konfigurieren eine einzelne verbundene Anwendung für mehrere Serviceanbieter.
• Ein Benutzer verwendet eine aktive Sitzung bei einem Serviceanbieter. Anschließend meldet sich der Benutzer bei einem anderen Serviceanbieter an, indem er dieselbe verbundene Anwendung verwendet, die für beide Serviceanbieter konfiguriert wurde.

Erstellen Sie für jeden Serviceanbieter eine eigene verbundene Anwendung, um sicherzustellen, dass unterschiedliche Serviceanbieter eindeutige Zugriffstoken erhalten.

Ein Client kann ein Aktualisierungstoken wiederholt verwenden, um Zugriff auf den Ressourcenserver zu erhalten. Wenn ein Aktualisierungstoken abläuft oder ein Benutzer es außerhalb des Clients widerruft, fordert der Client in der Regel ein neues Zugriffstoken an, indem er den Autorisierungs-Flow ganz neu implementiert.

Ein Aktualisierungstoken kann eine unbegrenzte Lebenszeit besitzen, so lange gültig sein wie vom Administrator konfiguriert oder so lange, bis es widerrufen wird. Der Client kann ein Aktualisierungstoken speichern und es verwenden, um neue Zugriffstoken zu erhalten. Aus Sicherheitsgründen muss der Client ein Aktualisierungstoken vor unautorisiertem Zugriff schützen.

Wenn die Anforderung den refresh_token- oder offline_access-Geltungsbereich enthält, können der OAuth 2.0-Benutzeragent und die OAuth 2.0-Webserver-Flows Aktualisierungstoken anfordern.

Das ID-Token ist eine signierte Datenstruktur, die authentifizierte Benutzerattribute enthält, einschließlich eines eindeutigen Kennzeichners für den Benutzer und des Zeitpunkts der Tokenausstellung. Darüber hinaus gibt es die anfordernde Client-Anwendung an. Salesforce kann auf eine OAuth-Anforderung mit einem ID-Token antworten, das den OpenID Connect-Spezifikationen entspricht.

Wenn die Anforderung diese Parameter enthält, können sowohl der OAuth 2.0-Benutzeragent- als auch der OAuth 2.0-Webserver-Flow ein signiertes ID-Token anfordern. Beim zurückgegebenen Token handelt es sich um ein JSON-Webtoken (JWT).

• Der Benutzeragenten-Flow muss den Parameter "response_type" mit dem Wert "token id_token", den Geltungsbereich "openid" und den Parameter "nonce" enthalten.
• Der Webserver-Flow muss den Parameter "response_type" mit dem Wert "code" und den Geltungsbereich "openid" enthalten. Der Parameter "nonce" ist optional.

https://MyDomainname.my.salesforce.com/services/oauth2/authorize?response_type=token+id_token
&redirect_uri=https://MyDomainName.my.salesforce.com/services/oauth2/success
&client_id=3MVG9lKcPoNINVBIPJjdw1J9LLJbP_pqwoJYyuisjQhr_LLurNDv7AgQvDTZwCoZuD_
3Oxug0sU3_WrBPd_Ax6Mcnlg5HSnLGQ&scope=openid&nonce=somevalue

Verwenden Sie die bereitgestellten öffentlichen Schlüssel, um zu überprüfen, ob es sich bei der Signatur in der Antwort um eine gültige Salesforce-Signatur handelt. Die Antwort unter myDomainName.my.salesforce.com/id/keys enthält JSON-formatierte Informationen zu den öffentlichen Schlüsseln, die für die Signierung verwendet wurden. Validieren Sie die Signatur anhand des Schlüssels mit dem richtigen kid-Wert, der die Versionsnummer angibt.

Ermöglicht den Zugriff auf die eindeutige ID des angemeldeten Benutzers für verbundene OpenID Connect-Anwendungen.

Verwenden Sie im OAuth 2.0-Benutzeragenten-Flow und im OAuth 2.0-Webserver-Flow den Geltungsbereich "openid". Neben dem Zugriffstoken können Sie mit diesem Umfang auch ein signiertes ID-Token empfangen, das den OpenID Connect-Spezifikationen entspricht.

Ermöglicht Zugriff auf alle für angemeldete Benutzer zugänglichen Daten und schließt alle anderen Umfänge ein.

"full" gibt kein Aktualisierungstoken zurück. Sie müssen explizit den Geltungsbereich "refresh_token" anfordern, um ein Aktualisierungstoken zu erhalten.

Lässt nur den Zugriff auf vom Kunden erstellte Visualforce-Seiten zu. Dieser Umfang lässt den Zugriff auf standardmäßige Salesforce-Benutzeroberflächen nicht zu.

Damit hybride Anwendungen untergeordnete Visualforce-Sitzungen direkt abrufen können, binden Sie diesen Umfang in den Token-Flow der OAuth 2.0-Hybridanwendung und den Aktualisierungstoken-Flow der OAuth 2.0-Hybridanwendung ein.