Entrant OAuth

  • Rversion finale: Zurich
  • Mis à jour 31 juil. 2025
  • 4 minutes de lecture

    • L’authentification entrante OAuth permet aux applications externes de confiance d’accéder en toute sécurité aux API ServiceNow, garantissant ainsi des connexions contrôlées et autorisées.

    Vous devez disposer de l’un des rôles suivants pour configurer ou gérer les intégrations OAuth dans le système :
    • oauth_admin
    • mi_admin
    • admin

    L’authentification entrante permet aux applications externes telles que des systèmes tiers ou d’autres ServiceNow® instances de se connecter en toute sécurité aux ServiceNow API. L’authentification entrante confirme que seuls les clients de confiance peuvent accéder à votre instance ServiceNow de manière contrôlée et sécurisée. ServiceNow prend en charge plusieurs types d’autorisations OAuth 2.0, chacun conçu pour des scénarios d’intégration spécifiques. Utilisez les informations suivantes pour choisir le type d’accord qui correspond le mieux à votre cas d’utilisation :

    Octroi du code d’autorisation

    Scénario d’utilisation idéal Fonction
    Applications qui doivent accéder aux données utilisateur pour le compte de l’utilisateur avec le consentement de l’utilisateur.

    Exemple : applications Web, mobiles ou de bureau agissant pour le compte d’un utilisateur.

    		 L’utilisateur lance le processus de connexion à partir de l’application cliente, qui le redirige vers une ServiceNow page de connexion. Une fois que l’utilisateur s’est connecté et a donné son consentement, l’application cliente reçoit un code d’autorisation. L’application cliente échange le code d’autorisation avec l’instance ServiceNow contre un jeton d’accès.

    L’octroi de code d’autorisation est le workflow le plus sécurisé et le plus utilisé pour les intégrations orientées utilisateur. Il prend en charge à la fois les clients confidentiels (avec un secret client) et les clients publics utilisant Proof Key for Code Exchange (PKCE).

    Pour plus d’informations sur le workflow et la configuration d’octroi du code d’autorisation, voir Attribution du code d'autorisation

    Octroi des informations d’identification du client

    Scénario d’utilisation idéal Fonction
    Les applications clientes telles que les services back-end ou les intégrations de systèmes automatisées qui doivent accéder aux ServiceNow API sans implication de l’utilisateur. L’application cliente s’authentifie directement auprès de l’instance à l’aide ServiceNow de ses propres informations d’identification (ID client et clé secrète). Une fois authentifiée, l’application reçoit un jeton d’accès ServiceNow pour accéder aux API.

    Pour plus d’informations sur le workflow et la configuration d’octroi des informations d’identification du client, reportez-vous à la section Attribution des informations d'identification du client.

    Flux de jetons d’ID tiers

    Scénario d’utilisation idéal Fonction
    Scénarios d’authentification fédérée où ServiceNow les trusts, l’identité ou les jetons d’accès émis par des fournisseurs d’identité externes tels que Azure AD ou Okta. L’application cliente obtient un ID ou un jeton d’accès auprès d’un fournisseur d’identité tiers de confiance et l’inclut dans l’en-tête d’autorisation lors des demandes d’API à l’instance ServiceNow . ServiceNow valide le jeton et, si elle est approuvée, accorde l’accès en fonction de l’identité qu’elle affirme. Cela permet une authentification unique (SSO) transparente et une authentification fédérée entre les systèmes.

    Pour plus d’informations sur le flux et la configuration des jetons tiers, consultezOctroi de jeton tiers.

    Bourse JWT Bearer

    Scénario d’utilisation idéal Fonction
    Applications clientes qui ont besoin d’un accès sécurisé aux ServiceNow ressources, soit pour le compte d’un utilisateur, soit en tant que lui-même, sans nécessiter d’interaction de l’utilisateur ni stocker de secret partagé.

    L’application cliente crée un jeton Web JSON signé (JWT) qui inclut les revendications liées à l’identité, telles que l’utilisateur ou le système qu’elle représente. Il le présente ensuite à l’instance ServiceNow pour demander un jeton d’accès.
    Lorsque vous agissez au nom d’un utilisateur :
    Le jeton représente un utilisateur précédemment authentifié. Cela permet un accès sécurisé et transparent sans avoir à demander à nouveau à l’utilisateur des informations d’identification ou son consentement. Le jeton signé affirme l’identité de l’utilisateur, ce qui permet ServiceNow de faire confiance à la demande sans nécessiter d’interaction en temps réel de l’utilisateur.
    Lorsqu’il agit en son propre nom :
    Le jeton identifie et authentifie directement l’application cliente. Au lieu d’utiliser un secret partagé, le client signe le jeton avec une clé privée, ce qui en fait une alternative plus sûre à l’octroi d’informations d’identification du client.

    Pour plus d’informations sur le workflow et la configuration de la subvention JWT Bearer, reportez-vous à la section Octroi de porteur de jeton Web JSON.

    Attribution des informations d’identification du mot de passe de propriétaire de ressource

    Scénario d’utilisation idéal Fonction
    Applications clientes internes hautement fiables dans des environnements contrôlés où l’application collecte directement les informations d’identification de l’utilisateur. L’application cliente collecte le nom d’utilisateur et le mot de passe de l’utilisateur et le redirige vers l’instance pour obtenir un jeton d’accès ServiceNow . Le workflow contourne les écrans de redirection et de consentement, mais expose les informations d’identification de l’utilisateur à l’application cliente. ServiceNow vous recommande d’implémenter les informations d’identification du mot de passe de propriétaire de ressource uniquement dans des environnements hérités ou contrôlés.

    Pour plus d’informations sur le workflow et la configuration d’octroi des informations d’identification de mot de passe de propriétaire de ressource, reportez-vous à la section Attribution des informations d’identification du mot de passe de propriétaire de ressource.

    Subventions implicites

    Scénario d’utilisation idéal Fonction
    Applications monopages (SPA) héritées ou applications basées sur un navigateur qui ne peuvent pas stocker en toute sécurité un secret client et nécessitent un flux d’authentification côté client léger. L’utilisateur se connecte via un navigateur. L’application cliente reçoit le jeton d’accès directement dans l’URL après la connexion, en ignorant l’étape du code d’autorisation intermédiaire.

    Ce flux a été conçu à l’origine pour les clients publics qui s’exécutent entièrement dans le navigateur, où il n’est pas possible de stocker des secrets en toute sécurité. Bien qu’il simplifie la mise en œuvre, il expose les jetons dans le navigateur, ce qui augmente le risque d’interception. Pour renforcer la sécurité, ServiceNow recommande d’implémenter l’octroi d’un code d’autorisation avec PKCE.

    Pour plus d’informations sur le workflow et la configuration de l’octroi implicite, reportez-vous à la section Attributions implicites OAuth.

    Périmètres OAuth

    Vous pouvez définir la prise en charge du périmètre d’authentification OAuth pour l’API REST. Le périmètre OAuth permet d’accéder uniquement aux API REST particulières. Pour plus d'informations, consultez Périmètre d'authentification REST API.