Empêcher les clients OAuth d’utiliser l’attribution implicite

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

    • Utilisez une propriété système pour éviter l’utilisation du type d’attribution implicite.

    L’octroi implicite OAuth a été créé pour surmonter une limitation entre les navigateurs et les applications côté client (par exemple, les applications à page unique) avant l’adoption généralisée du partage des ressources d’origine croisée (CORS). Plus précisément, la politique de même origine des navigateurs bloquait la demande d’échange du code d’autorisation OAuth avec le jeton d’accès OAuth. Étant donné que la prise en charge CORS est universelle, les clients OAuth n’ont pas besoin d’utiliser l’octroi implicite et les demandes de type d’accord implicite échouent par défaut.

    Les ID client répertoriés dans la glide.oauth.clients.allowed.for.implicit.grant propriété peuvent continuer à utiliser le type d’attribution implicite. Assurez-vous que la propriété n’existe pas dans la table Propriétés système [sys_properties], ou qu’elle existe, mais ne contient pas de valeur.

    Important :
    Le changement d’un client OAuth en un type d’accord différent peut nécessiter des changements de code ou de configuration dans l’application cliente (en dehors de la plateforme ServiceNow).

    En savoir plus

    Attribut Description
    Nom de la configuration glide.oauth.clients.allowed.for.implicit.grant
    Type de configuration Propriétés système (/sys_properties_list.do)
    Type de données Chaîne
    Valeur recommandée <vide>
    Valeur par défaut <vide>
    Valeur de secours <vide>
    Catégorie API et service web
    Risque de sécurité
    • Score de gravité : 3,9
    • Score CVSS : faible
    • Détails du risque de sécurité :

      Le type d’attribution implicite OAuth entraîne l’émission de jetons d’accès par le serveur d’autorisation dans la réponse d’autorisation, ce qui le rend vulnérable à la fuite de jetons d’accès et à la relecture des jetons d’accès. Cela signifie qu’un attaquant peut utiliser le jeton d’accès divulgué ou volé au niveau d’un point de terminaison de ressource.

      Dans l’attribution implicite, le serveur d’autorisation renvoie un jeton d’accès directement dans le fragment d’URL, ce qui peut causer des problèmes :

      1. Ce fragment d’URL peut être stocké dans l’historique du navigateur.
      2. Si la page charge ensuite des images ou suit des liens vers d’autres domaines, des parties de l’URL peuvent être divulguées via l’en-tête référent.
      3. Les serveurs Web, les équilibreurs de charge et les proxys peuvent enregistrer des URL complètes.
      4. Tout JavaScript s’exécutant sur la page (y compris le JS malveillant injecté) peut lire window.location.hash et extraire le jeton.

      Pour éviter ces problèmes, utilisez le type d’attribution de code d’autorisation plutôt que le type d’attribution implicite lorsqu’un utilisateur humain/interactif délègue l’autorisation au client.

      Références
    Impact fonctionnel

    La demande de type d’attribution implicite échoue immédiatement. Tous les clients OAuth avec le type d’accord implicite qui ne sont pas ajoutés à la propriété échouent par défaut.

    Si vous n’avez défini aucun client OAuth qui utilise le type d’attribution implicite, il n’y a aucun impact.

    Remarque :
    Le changement d’un client OAuth en un type d’accord différent peut nécessiter des changements de code ou de configuration dans l’application cliente (en dehors de la plateforme ServiceNow).
    Dépendances et prérequis Aucun