OAuth 2.0
Mit OAuth 2.0 können Benutzer über externe Clients auf Instanzressourcen zugreifen, indem sie ein Token erhalten, anstatt bei jeder Ressourcenanforderung Anmeldeinformationen einzugeben.
Um die OAuth-Integration zu verwalten, benötigen Sie die Rolle security_admin. Konfigurieren Sie OAuth 2.0 für die folgenden Szenarien:
- Szenario mit externem OAuth-Client (eingehend): Ihre Instanz bietet einen Endpunkt für Clients von Drittanbietern, um Daten aus der Instanz abzurufen.
- OAuth-Provider-Szenario (ausgehend): Ihre Instanz ruft Daten von einem Drittanbieter ab.
Sowohl einfache Sicherheits- als auch Hochsicherheits-Frameworks unterstützen OAuth 2.0. Hohe Sicherheit wird empfohlen. Unter finden Sie Informationen dazu, für welche Versionen bereits hohe Sicherheit aktiv ist und wie hohe Sicherheit aktiviert wird.
Schlüsselkonzepte der OAuth 2.0-Implementierung
| Konzept | Beschreibung |
|---|---|
| Ressourcenbesitzer | Eine Entität, die Zugriff auf eine geschützte Ressource gewähren kann. Ein Ressourcenbesitzer, der eine Person ist, wird als Endbenutzerbezeichnet. Der Ressourcenbesitzer ist immer ein Benutzeraccount. |
| Client | Eine Anwendung, die mit der Autorisierung des Ressourcenbesitzers Anforderungen für geschützte Ressourcen im Namen des Ressourcenbesitzers sendet. |
| Ressourcenserver | Der Server, der die geschützten Ressourcen hostet und Anforderungen für geschützte Ressourcen annehmen und beantworten kann. |
| Autorisierungsserver | Der Server, der nach erfolgreicher Authentifizierung des Ressourcenbesitzers und Erhalt der Autorisierung Zugriffstoken an den Client ausgibt. |
| Autorisierungsanforderung | Die Berechtigung, die ein Client für den Zugriff auf eine geschützte Ressource benötigt. Die Autorisierungsanforderung ist immer eine HTTP-POST-Nachricht, die die ID des Clients enthält, der im Namen des Ressourcenbesitzers handelt, und Anmeldeinformationen, die die Anforderung autorisieren. |
| Autorisierung Gewährung | Anmeldeinformationen, die die Autorisierung des Ressourcenbesitzers für den Zugriff auf eine Ressource darstellen. Bei der Autorisierungsgewährung handelt es sich entweder um Anmeldeinformationen des Benutzers oder ein Aktualisierungstoken. |
| Zugriffs-Token | Eine sichere Zeichenfolge, die ein Client für den Zugriff auf geschützte Ressourcen verwendet. Eine Instanz gibt Zugriffstoken an Clients aus, die über eine gültige Autorisierungsgewährung verfügen. Jedes Zugriffstoken hat einen bestimmten Bereich, eine bestimmte Lebensdauer und andere Attribute. Standardmäßig gibt eine Instanz Zugriffstoken mit einer Lebensdauer von 30 Minuten aus, wenn die Instanz der OAuth-Provider ist. Für Drittanbieter-Token 30 Tage. |
| Token neu laden | Anmeldeinformationen, die ein Client verwendet, um neue Zugriffstoken zu erhalten, ohne dass eine zusätzliche Benutzerautorisierung erforderlich ist. Eine Instanz gibt ein Aktualisierungstoken an einen Client aus, wenn er zum ersten Mal für ein Zugriffstoken autorisiert wird. Standardmäßig gibt eine Instanz Aktualisierungstoken mit einer Lebensdauer von 100 Tagen aus, wenn die Instanz der OAuth-Provider ist. Für Drittpartei-Token 365 Tage. |
| Selbstsignierte Zertifikate | Now Platform unterstützt keine selbstsignierten Zertifikate. Der OAuth-Client verwendet den Zertifikat-Truststore nicht und lässt keine Verbindung zu OAuth-Endpunkten zu, die ein selbstsigniertes Zertifikat enthalten. |
| Benutzeragent | Der Benutzer, der Zugriffsrechte für eine Client-Anwendung delegiert, bei der es sich häufig um eine Website handelt. Die Zugriffsrechte ermöglichen es der Clientanwendung oder Website, auf Daten in der Instanz zuzugreifen, für die der Benutzer Zugriffsrechte hat. Der Benutzeragent wird im Szenario verwendet. |
OAuth-Gewährungstypen
- Autorisierungscode: Der Verbraucher erhält zuerst einen Autorisierungscode und verwendet ihn dann, um ein Zugriffstoken zu erhalten. Sie können ein OAuth-Profil angeben und diesen Gewährungstyp angeben. Der Prozess, bei dem der Autorisierungscode verwendet wird, wird auch als Authentifizierungscode -Flow oder Autorisierungscode-Flow bezeichnet.
- Passwort-Anmeldeinformationendes Ressourcenbesitzers: Der Verbraucher der Ressource verfügt bereits über die Anmeldeinformationen des Benutzers, um das Zugriffstoken zu erhalten. Dieser Prozess wird auch als Passwort-Flowbezeichnet.
- Client-Anmeldeinformationen: Der Verbraucher der Ressource verwendet die Client-ID und den geheimen Clientschlüssel, die bereits in der Anwendungsregistrierung konfiguriert sind.
Speicherung von Authentifizierungsanmeldeinformationen
Der OAuth-Clientschlüssel wird als Feld vom Typ password2 gespeichert, das mit KMF verschlüsselt ist. Benutzerpasswörter, die zur Überprüfung eingehender Endpunktanforderungen verwendet werden, werden als Hash-Wert in der Benutzertabelle in einem Feld vom Typ password (SHA 256) gespeichert. Weitere Informationen zu dieser Verschlüsselung finden Sie unter Password2-Verschlüsselung mit KMF