OAuth 2.0

  • Rversion finale: Australia
  • Mis à jour 12 mars 2026
  • 3 minutes de lecture

    • OAuth 2.0 permet aux utilisateurs d’accéder aux ressources d’instance via des clients externes en obtenant un jeton plutôt qu’en saisissant des informations d’identification de connexion à chaque demande de ressource.

    Vous devez disposer du rôle security_admin pour gérer l’intégration OAuth. Configurez OAuth 2.0 pour les scénarios suivants :

    • Scénario de client externe OAuth (entrant) : votre instance fournit un point de terminaison permettant aux clients tiers d’extraire des données de l’instance.
    • Scénario du fournisseur OAuth (sortant) : votre instance extrait les données d’un fournisseur tiers.
    Remarque :
    Vous devez vous authentifier pour la première fois pour récupérer la publication du jeton, ce que vous n’avez pas besoin d’authentifier à l’aide d’un compte utilisateur avant l’expiration du jeton.

    Les frameworks de sécurité simple et de haute sécurité prennent en charge OAuth 2.0. Une sécurité élevée est recommandée. Consultez pour plus d’informations sur les versions pour lesquelles la haute sécurité est déjà active et sur la façon d’activer la haute sécurité.

    Concepts clés de la mise en œuvre d’OAuth 2.0

    Concept Description
    Propriétaire de ressource Entité capable d’accorder l’accès à une ressource protégée. Un propriétaire de ressource qui est une personne est appelé utilisateur final. Le propriétaire de ressource est toujours un compte d’utilisateur.
    Client Application qui, avec l’autorisation du propriétaire de ressource, effectue des demandes de ressources protégées au nom du propriétaire de ressource.
    Serveur de ressources Serveur qui héberge les ressources protégées, capable d’accepter les demandes de ressources protégées et d’y répondre.
    Serveur d’autorisation Serveur qui émet des jetons d’accès au client après avoir authentifié le propriétaire de ressource et obtenu l’autorisation.
    Demande d’autorisation Autorisation dont un client a besoin pour accéder à une ressource protégée. La demande d’autorisation est toujours un message HTTP POST contenant l’ID du client qui agit au nom du propriétaire de ressource et les informations d’identification qui autorisent la demande.
    Octroi de l’autorisation Informations d’identification qui représentent l’autorisation du propriétaire de ressource à accéder à une ressource. L’attribution de l’autorisation se fait soit par des informations d’identification de connexion de l’utilisateur, soit par un jeton d’actualisation.
    Jeton d'accès Chaîne sécurisée qu’un client utilise pour accéder aux ressources protégées. Une instance émet des jetons d’accès aux clients disposant d’une autorisation valide. Chaque jeton d’accès a un périmètre, une durée de vie et d’autres attributs spécifiques.

    Par défaut, une instance émet des jetons d’accès d’une durée de vie de 30 minutes dans le scénario où l’instance est le fournisseur OAuth. Pour les jetons tiers, 30 jours.
    Actualiser le jeton Informations d’identification qu’un client utilise pour obtenir de nouveaux jetons d’accès sans nécessiter d’autorisation utilisateur supplémentaire. Une instance émet un jeton d’actualisation à un client lorsqu’elle est autorisée pour la première fois à disposer d’un jeton d’accès.

    Par défaut, une instance émet des jetons d’actualisation avec une durée de vie de 100 jours dans le scénario où l’instance est le fournisseur OAuth. Pour les jetons tiers, 365 jours.
    Certificats auto-signés La ne ServiceNow AI Platform prend pas en charge les certificats auto-signés. Le client OAuth n’utilise pas le magasin de confiance de certificat et n’autorise pas la connexion aux points de terminaison OAuth qui intègrent un certificat auto-signé.
    Agent utilisateur Utilisateur qui délègue les droits d’accès à une application cliente, qui est souvent un site web. Les droits d’accès permettent à l’application ou au site Web client d’accéder aux données dans l’instance à laquelle l’utilisateur a des droits d’accès. L’agent utilisateur est utilisé dans le scénario.

    Types d’accords OAuth

    Un type d’accord est la façon dont le client obtient le jeton d’accès. Les types d’octroi suivants sont pris en charge :
    • Code d’autorisation : le consommateur obtient d’abord un code d’autorisation, puis l’utilise pour obtenir un jeton d’accès. Vous pouvez spécifier un profil OAuth et spécifier ce type d’accord. Le processus qui utilise le code d’autorisation est également appelé flux de code d’authentification ou flux de code d’autorisation.
    • Informations d’identification du mot de passe du propriétaire de ressource : le consommateur de la ressource dispose déjà des informations d’identification de l’utilisateur pour obtenir le jeton d’accès. Ce processus est également appelé flux de mots de passe.
    • Informations d’identification du client : le consommateur de la ressource utilise l’ID client et le secret client déjà configurés dans le registre d’application.

    Stockage des informations d’identification d’authentification

    Le secret client OAuth est stocké en tant que password2 champ de type, chiffré avec KMF. Les mots de passe utilisateur, qui sont utilisés pour vérifier les demandes de point de terminaison entrantes, sont stockés en tant que valeur de hachage dans la table Utilisateur dans un password champ type (SHA 256). Pour plus de détails sur ce chiffrement, consultez Chiffrement Password2 avec KMF