OAuth 2.0

  • Rversion finale: Washingtondc
  • Mis à jour 1 févr. 2024
  • 3 minutes de lecture

    • OAuth 2.0 permet aux utilisateurs d’accéder aux ressources de l’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 authentifier l’utilisateur pour la première fois afin de récupérer le jeton, ce qui signifie que vous n’avez pas besoin de vous authentifier à l’aide d’un compte d’utilisateur avant l’expiration du jeton.

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

    Concepts clés de l’implémentation 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é un utilisateur final. Le propriétaire de la ressource est toujours un compte utilisateur.
    Client Application qui, avec l’autorisation du propriétaire de la ressource, effectue des demandes de ressources protégées au nom du propriétaire de la ressource.
    Serveur de ressources Serveur qui héberge les ressources protégées, capable d’accepter et de répondre aux demandes de ressources protégées.
    Serveur d'autorisation Serveur qui émet des jetons d’accès au client après avoir authentifié le propriétaire de la ressource et obtenu l’autorisation.
    Demande d’autorisation Autorisation requise par un client pour accéder à une ressource protégée. La demande d’autorisation est toujours un message HTTP POST qui contient l’ID du client qui agit au nom du propriétaire de la ressource et les informations d’identification qui autorisent la demande.
    Octroi d’autorisation Informations d’identification qui représentent l’autorisation du propriétaire de la ressource d’accéder à une ressource. L’autorisation accordée est soit les informations d’identification de connexion de l’utilisateur, soit 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 champ d’application, 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’il est autorisé pour la première fois à disposer d’un jeton d’accès.

    Par défaut, une instance émet des jetons d’actualisation d’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 Le Now Platform ne prend pas en charge les certificats autosignés. Le client OAuth n’utilise pas le magasin de certificats de confiance et n’autorise pas la connexion à des points de terminaison OAuth qui incorporent un certificat autosigné.
    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 cliente ou au site web 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’octroi désigne la manière dont le client obtient le jeton d’accès. Les types de subventions 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’autorisation ou flux de code d’autorisation.
    • Informations d’identification du mot de passe du propriétaire de la ressource : le consommateur de la ressource possède déjà les 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é sous la forme d’un password2 champ 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 sous forme de valeur de hachage dans la table Utilisateur dans un password champ de type (SHA 256). Pour plus d’informations sur ce chiffrement, consultez Chiffrement Password2 avec KMF