Sie befinden sich hier:
JWT-basierte Zugriffstoken
Salesforce unterstützt zwei Typen von Zugriffstoken: opake Token und JSON-Webtoken(JWT)-basierte Zugriffstoken. Ein opakes Zugriffstoken wird als Zeichenfolge formatiert, die nicht decodiert werden kann, es sei denn, Sie rufen den Endpunkt "Salesforce-Benutzerinfo" auf. Ein JWT-basiertes Zugriffstoken wird als JSON-Objekt formatiert, das alle Informationen enthält, die zum Autorisieren einer Anwendung erforderlich sind. Dieses transparente Format erleichtert die Verwendung von JWT-basierten Zugriffstoken für Services, die außerhalb der Salesforce-Plattform entwickelt wurden. Sie können JWT-basierte Zugriffstoken einfach lokal in Ihrem Service außerhalb der Plattform analysieren und validieren, ohne einen Salesforce-Endpunkt aufzurufen. Durch die lokale Selbstprüfung von Token können Sie die Leistung und die Effizienz Ihrer Autorisierungs-Flows verbessern.
Erforderliche Editionen
| Verfügbarkeit: Salesforce Classic und Lightning Experience |
| Verfügbarkeit: Alle Editionen |
Im Vergleich zu opaken Zugriffstoken weisen JWT-basierte Zugriffstoken unterschiedliche Funktionen und Einschränkungen auf. Beispielsweise können JWT-basierte Zugriffstoken nur für den Zugriff auf REST-APIs verwendet werden. Informationen zum Vergleich der Token-Typen finden Sie in der Salesforce-Hilfe unter Zugriffstoken.
Sie können JWT-basierte Zugriffstoken für alle Autorisierungs-Flows ausstellen.
Token-Format
JWT-basierte Zugriffstoken verwenden die JWT-Struktur, die einen Header, eine Nutzlast und eine Signatur umfasst. Der Header enthält Informationen zum Token, beispielsweise den Token-Typ. Die Nutzlast enthält einen Satz von Claims mit Informationen über das Token, den Benutzer und die Anwendung. Der Signaturteil enthält die kryptografische Signatur des Tokens. Diese Signatur besteht aus dem Base64-codierten Header und der Nutzlast sowie einem Geheimnis und wird mit dem im alg-Claim angegebenen Algorithmus signiert.
Hier finden Sie eine detaillierte Übersicht über den Header und die Nutzlast.
| Header-Claim | Beschreibung |
|---|---|
alg (Algorithmus) |
Der zum Signieren des JWT-basierten Zugriffstokens verwendete Algorithmus, mit dem Sie überprüfen können, dass sich das Token seit seiner Ausstellung nicht geändert hat. Salesforce unterstützt nur den RS256-Algorithmus. Daher muss der Wert dieses Claims RS256 lauten. |
typ (Typ) |
Der Typ des im Token gespeicherten Inhalts. Mit diesem Claim können Anwendungen das Token von anderen Datentypen unterscheiden. Bei JWT-basierten Zugriffstoken lautet dieser Wert JWT. |
kid (Schlüssel-ID) |
Eine bei Salesforce registrierte Zeichenfolge, die angibt, dass ein Schlüssel zum Signieren des Tokens verwendet wurde, wodurch die Authentizität besser belegt werden kann. |
tty (Token-Typ) |
Der Token-Typ. Der Wert ist auf sfdc-core-token festgelegt. |
tnk (Mandantenschlüssel) |
Der Mandantenschlüssel, der die Salesforce-Organisation identifiziert, die das JWT-basierte Zugriffstoken ausgestellt hat. Dieser Wert wird definiert, sodass Salesforce die richtigen öffentlichen Schlüssel für die betreffende Organisation finden und überprüfen kann. |
ver (Version) |
Die Version der JWT-Bibliothek. |
Hier ein Beispiel-Header.
{
"tnk": "example/00XXXXXX",
"ver": "1.0",
"kid": "CORE_ATJWT************",
"tty": "sfdc-core-token",
"typ": "JWT",
"alg": "RS256"
}Die Nutzlast enthält immer die folgenden Claims.
| Nutzlastanspruch | Beschreibung |
|---|---|
aud (Zielgruppe) |
Die vorgesehene Zielgruppe des JWT-Zugriffstokens, wie vom jeweiligen Anwendungsfall bestimmt. Der aud-Claim wird als JSON-Array von Zeichenfolgen formatiert. |
exp (Ablaufzeit) |
Die Ablaufzeit des JWT-Zugriffstokens. Das Token kann ab diesem Zeitpunkt nicht mehr akzeptiert werden. Die Ablaufzeit muss nach dem aktuellen Datum und der aktuellen Uhrzeit liegen. |
iss (Aussteller) |
Der URL der Site "Meine Domäne" oder der Experience Cloud-Site, die das JWT-Zugriffstoken ausstellt. Beispiel: MyDomainName.my.site.com. |
mty
|
Nur zur internen Verwendung. |
nbf (nicht vor einer bestimmten Uhrzeit) |
Der Client muss das JWT nach dem im nbf-Claim angegebenen Zeitpunkt (Datum und Uhrzeit) erhalten. Wenn das JWT vor diesem Zeitpunkt gesendet wird, kann der Client es nicht akzeptieren. |
sfi
|
Interner Kennzeichner, der für die spätere Verwendung reserviert ist. |
sub (Betreff) |
Gibt den Benutzer an, der Antragsteller des JWT-Zugriffstokens ist. Dem Wert
|
scp (Umfänge) |
Eine Liste der von Salesforce unterstützten Umfänge, einschließlich benutzerdefinierter Umfänge, formatiert als JSON-Array von Umfangsnamen. Die Umfänge werden durch Leerzeichen getrennt. Das Token kann alle Salesforce-Geltungsbereiche außer dem full-Geltungsbereich enthalten. |
Die Nutzlast kann zudem die folgenden optionalen Claims enthalten.
| Nutzlastanspruch | Beschreibung |
|---|---|
acx
|
Nur zur internen Verwendung. |
client_id (Verbraucherschlüssel) |
Der Verbraucherschlüssel der externen Salesforce-Client-Anwendung oder der verbundenen Anwendung, die das Token ausgestellt hat. |
iat (ausgestellt um) |
Der Zeitpunkt, zu dem das JWT ausgestellt wurde. Sie können den Wert dieses Claims verwenden, um herauszufinden, wie alt das JWT ist. |
roles (Rollenliste) |
Definiert die Eigenschaften für das Token, das von Services zum Steuern des Zugriffs verwendet werden kann, beispielsweise Berechtigungssätze und Rollen. Die Werte in diesem Claim werden vollständig von Salesforce gesteuert. Der Claim enthält keine umfassende Liste der Zugriffsberechtigungen eines Benutzers. Beispielsweise wird ein dem Benutzer zugewiesener Berechtigungssatz manchmal nicht in dieser Liste angezeigt. Die Werte in diesem Claim sind als Array von Zeichenfolgen mit Präfix formatiert. Salesforce unterstützt diese Präfixe.
Manchmal ist dieser Claim ein leeres Array. |
obo (im Namen von) |
Jeder, der über das Token verfügt, kann Aktionen im Namen des Werts in diesem Claim ausführen. Bei Salesforce wird mit diesem Claim eine UVID mit einem benannten Benutzer verknüpft, wenn Sie ein Gasttoken in einen Flow für einen benannten Benutzer übergeben. Das Gasttoken enthält die UVID im sub-Claim. Nach dem Abschließen eines Flows für einen benannten Benutzer fügt das neue Zugriffstoken die UVID im obo-Claim hinzu und speichert die Benutzer-ID im sub-Claim. |
Hier eine Beispiel-Nutzlast. Da in diesem Beispiel eine UVID im obo-Claim vorliegt, können Sie davon ausgehen, dass dieses Token ausgestellt wurde, nachdem eine UVID in einen Flow für einen benannten Benutzer übergeben wurde.
{
"scp": "api",
"aud": [
"https://example.com"
],
"sub": "uid:005x00000000001",
"nbf": "1675197036",
"iss": "https://example.com", "exp": "1675198836",
"iat": "1675197036",
“obo”: “uvid:abcd-1234-efgh”,
"client_id": "***********",
“mty”: “oauth”,
“sfi”: “********”
}
