OAuth eingehend

  • Freigeben Version: Zurich
  • Aktualisiert 31. Juli 2025
  • 3 Minuten Lesedauer

    • Die eingehende OAuth-Authentifizierung ermöglicht vertrauenswürdigen externen Anwendungen den sicheren Zugriff auf ServiceNow-APIs, wodurch kontrollierte und autorisierte Verbindungen sichergestellt werden.

    Sie müssen über eine der folgenden Rollen verfügen, um OAuth-Integrationen im System zu konfigurieren oder zu verwalten:
    • oauth_admin
    • Mi_admin
    • admin

    Die eingehende Authentifizierung ermöglicht externe Anwendungen wie Drittparteisysteme oder andere ServiceNow® Instanzen, mit denen eine sichere Verbindung hergestellt werden soll ServiceNow APIs. Die eingehende Authentifizierung bestätigt, dass nur vertrauenswürdige Clients kontrolliert und sicher auf Ihre ServiceNow-Instanz zugreifen können. ServiceNow Unterstützt mehrere OAuth 2,0-Gewährungstypen, die jeweils für bestimmte Integrationsszenarien konzipiert sind. Verwenden Sie die folgenden Informationen, um den Gewährungstyp auszuwählen, der am besten zu Ihrem Anwendungsfall passt:

    Autorisierungscode-Gewährung

    Ideales Nutzungsszenario Funktionalität
    Anwendungen, die im Namen des Anwenders mit Zustimmung des Anwenders auf Anwenderdaten zugreifen müssen.

    Beispiel: Web-, Mobile- oder Desktop-Anwendungen, die im Namen eines Anwenders handeln.

    		 Der Anwender initiiert den Anmeldeprozess von der Client-Anwendung aus, die ihn an eine umleitet ServiceNow Anmeldeseite. Nachdem sich der Anwender angemeldet hat und seine Zustimmung erteilt hat, erhält die Client-Anwendung einen Autorisierungscode. Die Client-Anwendung tauscht den Autorisierungscode mit aus ServiceNow Instanz für ein Zugriffstoken.

    Die Autorisierungscodegewährung ist der sicherste und am häufigsten verwendete Workflow für anwenderorientierte Integrationen. Es unterstützt sowohl vertrauliche Clients (mit einem geheimen Client) als auch öffentliche Clients, die den Nachweisschlüssel für Code Exchange (PKCE) verwenden.

    Weitere Informationen zum Workflow und zur Konfiguration der Autorisierungscodegewährung finden Sie unter Autorisierungscodegewährung

    Client-Anmeldeinformationen Gewähren

    Ideales Nutzungsszenario Funktionalität
    Client-Anwendungen wie Back-End-Services oder automatisierte Systemintegrationen, auf die zugegriffen werden muss ServiceNow APIs ohne Anwenderbeteiligung. Die Client-Anwendung authentifiziert sich direkt bei ServiceNow Instanz mit eigenen Anmeldeinformationen (Client-ID und Geheimnis). Nach der Authentifizierung erhält die Anwendung ein Zugriffstoken für den Zugriff auf ServiceNow APIs.

    Weitere Informationen zum Workflow und zur Konfiguration von Client-Anmeldeinformationen finden Sie unter Gewährung von Client-Anmeldeinformationen.

    Drittpartei-ID-Token-Flow

    Ideales Nutzungsszenario Funktionalität
    Verbundauthentifizierungsszenarien, wo ServiceNow Vertraut auf Identitäts- oder Zugriffstoken, die von externen Identitätsanbietern wie ausgestellt wurden Azure AD oder Okta. Die Clientanwendung ruft eine ID oder ein Zugriffstoken von einem vertrauenswürdigen Drittanbieter von Identitäten ab und fügt sie in den Autorisierungsheader ein, wenn API-Anforderungen an den gestellt werden ServiceNow Instanz. ServiceNow Validiert das Token und gewährt, wenn vertrauenswürdig, Zugriff basierend auf der von ihm bestätigten Identität. Dies ermöglicht nahtloses Single Sign-on (SSO) und die systemübergreifende Verbundauthentifizierung.

    Weitere Informationen zum Flow und zur Konfiguration von Drittpartei-Token finden Sie unter Drittpartei-Tokengewährung.

    JWT-Bearer-Gewährung

    Ideales Nutzungsszenario Funktionalität
    Client-Anwendungen, die sicheren Zugriff auf benötigen ServiceNow Ressourcen, entweder im Namen eines Anwenders oder als sich selbst, ohne Anwenderinteraktion oder Speicherung eines gemeinsam genutzten Geheimnisses zu erfordern.

    Die Clientanwendung erstellt ein signiertes JSON-Webtoken (JWT), das identitätsbezogene Ansprüche enthält, z. B. den Anwender oder das System, das sie darstellt. Dann wird sie dem angezeigt ServiceNow Instanz, um das Zugriffstoken anzufordern.
    Wenn Sie im Namen eines Anwenders handeln:
    Das Token stellt einen zuvor authentifizierten Anwender dar. Dies ermöglicht einen sicheren, nahtlosen Zugriff, ohne den Anwender erneut zur Eingabe von Anmeldeinformationen oder Einwilligung aufzufordern. Das signierte Token bestätigt die Identität des Anwenders, wodurch aktiviert wird ServiceNow Um der Anforderung zu vertrauen, ohne dass eine Echtzeitinteraktion des Anwenders erforderlich ist.
    Wenn Sie als sich selbst agieren:
    Das Token identifiziert und authentifiziert die Client-Anwendung direkt. Anstatt ein gemeinsames Geheimnis zu verwenden, signiert der Client das Token mit einem privaten Schlüssel, was es zu einer sichereren Alternative zur Gewährung von Client-Anmeldeinformationen macht.

    Weitere Informationen zum Workflow und zur Konfiguration der JWT-Bearer-Gewährung finden Sie unter JSON-Webtoken-Bearer-Gewährung.

    Zuteilung Von Passwortanmeldeinformationen Des Ressourcenbesitzers

    Ideales Nutzungsszenario Funktionalität
    Sehr vertrauenswürdige interne Client-Anwendungen in kontrollierten Umgebungen, in denen die App die Anmeldeinformationen des Anwenders direkt erfasst. Die Client-Anwendung erfasst den Anwendernamen und das Passwort des Anwenders und leitet sie an den weiter ServiceNow Instanz zum Abrufen eines Zugriffstoken. Der Workflow umgeht Umleitungs- und Einwilligungsbildschirme, stellt der Client-Anwendung jedoch Anwenderanmeldeinformationen zur Verfügung. ServiceNow Empfiehlt, dass Sie die Zuteilung von Passwortanmeldeinformationen für den Ressourcenbesitzer nur in Legacy- oder kontrollierten Umgebungen implementieren.

    Weitere Informationen zum Workflow und zur Konfiguration von Passwortanmeldeinformationen des Ressourcenbesitzers finden Sie unter Zuteilung der Passwortanmeldeinformationen des Ressourcenbesitzers.

    Implizite Zuschüsse

    Ideales Nutzungsszenario Funktionalität
    Legacy-einseitige Anwendungen (SPAs) oder browserbasierte Apps, die ein geheimes Clientgeheimnis nicht sicher speichern können und einen schlanken, clientseitigen Authentifizierungs-Flow erfordern. Der Anwender meldet sich über einen Browser an. Die Clientanwendung empfängt das Zugriffstoken nach der Anmeldung direkt in der URL, wobei der Schritt des Zwischen-Autorisierungscodes umgangen wird.

    Dieser Flow wurde ursprünglich für öffentliche Clients konzipiert, die vollständig im Browser ausgeführt werden, bei denen das sichere Speichern von Geheimnissen nicht möglich ist. Die Implementierung wird zwar vereinfacht, aber Token werden im Browser bereitgestellt, was das Abfangerrisiko erhöht. Für mehr Sicherheit ServiceNow Empfiehlt die Implementierung einer Autorisierungscodegewährung mit PKCE.

    Weitere Informationen zum Workflow und zur Konfiguration impliziter Zuschüsse finden Sie unter Implizite OAuth-Berechtigungen.

    OAuth-Bereiche

    Sie können den Umfang der Unterstützung des OAuth-Authentifizierungsbereichs für DIE REST-API erweitern. Der OAuth-Bereich bietet nur Zugriff auf die bestimmten REST-APIs. Weitere Informationen finden Sie unter REST-API-Authentifizierungsbereich.