OAuth 2.0

  • Freigeben Version: Xanadu
  • Aktualisiert 1. August 2024
  • 3 Minuten Lesedauer

    • Mit OAuth 2.0 können Anwender über externe Clients auf Instanzressourcen zugreifen, indem sie ein Token abrufen, anstatt bei jeder Ressourcenanforderung Anmeldeinformationen einzugeben.

    Sie müssen über die Rolle security_admin verfügen, um die OAuth-Integration zu verwalten. Konfigurieren Sie OAuth 2.0 für die folgenden Szenarien:

    • Szenario mit externem OAuth-Client (eingehend): Ihre Instanz von bietet einen Endpunkt für Drittanbieter-Clients, um Daten aus der Instanz abzurufen.
    • OAuth-Provider-Szenario (ausgehend): Ihre -Instanz ruft Daten von einem Drittanbieter ab.
    Hinweis:
    Sie müssen sich zum ersten Mal als Anwender authentifizieren, um den Token-Post abzurufen. Sie müssen sich nicht vor Ablauf des Tokens mit einem Anwenderaccount authentifizieren.

    Sowohl einfache Sicherheits-Frameworks als auch Hochsicherheits-Frameworks unterstützen OAuth 2.0. Hochsicherheit wird empfohlen. Unter finden Sie Informationen dazu, für welche Versionen bereits hohe Sicherheit aktiviert ist und wie Sie die hohe Sicherheit aktivieren.

    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 Endanwenderbezeichnet. Der Besitzer der Ressource ist immer ein Benutzeraccount.
    Client Eine Anwendung, die mit der Autorisierung des Ressourcenbesitzers im Namen des Ressourcenbesitzers Anforderungen für geschützte Ressourcen stellt.
    Ressourcenserver Der Server, der die geschützten Ressourcen hostet und Anforderungen für geschützte Ressourcen annehmen und beantworten kann.
    Autorisierungsserver Der Server, der Zugriffstoken an den Client ausgibt, nachdem der Ressourcenbesitzer erfolgreich authentifiziert und die Autorisierung erhalten wurde.
    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.
    Autorisierungserteilung Anmeldeinformationen, die die Autorisierung des Ressourcenbesitzers zum Zugriff auf eine Ressource darstellen. Bei der Autorisierungsgewährung handelt es sich entweder um Anmeldeinformationen oder um 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 Autorisierung verfügen. Jedes Zugriffstoken hat einen bestimmten Umfang, eine bestimmte Lebensdauer und andere Attribute.

    Standardmäßig gibt eine Instanz Zugriffstoken mit einer Lebensdauer von 30 Minuten aus, wenn die Instanz der OAuth-Anbieter ist. Für Drittpartei-Token 30 Tage.
    Token neu laden Anmeldeinformationen, mit denen ein Client neue Zugriffstoken erhält, ohne dass eine zusätzliche Benutzerautorisierung erforderlich ist. Eine Instanz gibt ein Aktualisierungstoken an einen Client aus, wenn sie zum ersten Mal autorisiert wird, über ein Zugriffstoken zu verfügen.

    Standardmäßig gibt eine Instanz Aktualisierungstoken mit einer Lebensdauer von 100 Tagen aus, wenn die Instanz der OAuth-Anbieter ist. Für Drittpartei-Token: 365 Tage.
    Selbstsignierte Zertifikate Now Platform unterstützt keine selbstsignierten Zertifikate. Der OAuth-Client verwendet nicht den Zertifikat-Trust-Store und lässt auch keine Verbindung mit OAuth-Endpunkten zu, die ein selbstsigniertes Zertifikat enthalten.
    Anwenderagent Der Benutzer, der Zugriffsrechte an eine Client-Anwendung delegiert, häufig eine Website. Die Zugriffsrechte ermöglichen der Client-Anwendung oder der Website den Zugriff auf Daten in der Instanz, für die der Benutzer über Zugriffsrechte verfügt. Der Benutzeragent wird im Szenario verwendet.

    OAuth-Gewährungstypen

    Mit einem Gewährungstyp erhält der Client das Zugriffstoken. Die folgenden Förderungstypen werden unterstützt:
    • 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, der den Autorisierungscode verwendet, wird auch als Autorisierungscode- Flow oder Autorisierungscode-Flow bezeichnet.
    • Passwort-Anmeldeinformationendes Ressourcenbesitzers: Der Verbraucher der Ressource verfügt bereits über die Anmeldeinformationen, 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 Anmeldeinformationen für die Authentifizierung

    Der OAuth-Clientschlüssel wird als Feld vom Typ password2 gespeichert, das mit KMF verschlüsselt ist. Anwenderpasswörter, die zur Überprüfung eingehender Endpunktanforderungen verwendet werden, werden als Hash-Wert in der Tabelle „Anwender“ im Typfeld password (SHA 256) gespeichert. Weitere Informationen zu dieser Verschlüsselung finden Sie unter Password2-Verschlüsselung mit KMF