Workflow d’octroi de code d’autorisation

  • Rversion finale: Zurich
  • Mis à jour 13 mars 2026
  • 6 minutes de lecture

    • L’attribution du code d’autorisation OAuth est un flux sécurisé et largement utilisé pour les applications Web, mobiles ou de bureau qui accèdent aux données utilisateur avec son consentement. Il prend en charge à la fois les clients privés (à l’aide d’un secret client) et les clients publics (à l’aide de PKCE).

    Avant de commencer

    Rôle requis : oauth_admin, mi_admin, admin

    Pourquoi et quand exécuter cette tâche

    Cette collection de rubriques fournit des informations sur la façon dont une application cliente peut utiliser le flux d’octroi du code d’autorisation pour obtenir un jeton de ServiceNow et effectuer des appels d’API avec ce jeton. Les clients privés utilisent le secret client, tandis que les clients publics utilisent le défi de code PKCE.

    Figure 1. Workflow d’autorisation
    Workflow d’autorisation

    Procédure

    1. Connectez-vous à partir de l’application cliente.

      L’utilisateur commence le processus de connexion à partir de l’interface de l’application cliente.

    2. Lancez la demande d’autorisation.

      Le client redirige l’utilisateur vers le point de terminaison d’autorisation ServiceNow. La méthode d’initiation de la demande d’autorisation dépend du type de client : public ou privé.

      Clients publics

      Les clients publics (exemple : applications mobiles ou à page unique) ne peuvent pas stocker un secret client en toute sécurité. Par conséquent, ils doivent utiliser la clé de preuve pour l’échange de code (PKCE) pour renforcer la sécurité.

      • Dans la demande d’autorisation, incluez la contestation de code PKCE et spécifiez la méthode de contestation de code.
      • Pendant la demande de jeton, le client doit envoyer le vérificateur de code pour valider le code d’autorisation.
      Effectuez une demande GET au point de terminaison d’autorisation avec les paramètres suivants :
      Method: GET
Endpoint: https://<servicenow_base_url>/oauth_auth.do
      Tableau 1. Paramètres de demande d’autorisation (Client public : PKCE)
      Paramètre Obligatoire Description
      response_type Oui Définissez la valeur sur code pour lancer le flux de code d’autorisation.
      client_id Oui L’identificateur unique pour votre application cliente.

      Format : YOUR_CLIENT_ID
      redirect_uri Oui L’URI auquel ServiceNow envoie le code d’autorisation.

      Exemple : https://yourapp.com/callback
      code_challenge Oui Hachage SHA-256 encodé en base64url du vérificateur de code. Ceci est utilisé dans le cadre du flux PKCE.
      code_challenge_method Oui Spécifie la méthode de transformation utilisée pour le test de code. Réglez sur S256.
      périmètre Facultatif Une liste de champs d’application demandés séparés par des espaces.

      Exemple : incident_read incident_write.
      État Oui Une valeur générée par le client utilisée pour éviter les attaques CSRF. La valeur est renvoyée inchangée dans l’URI de redirection, ce qui permet au client de la valider.
      Remarque :
      À partir de la version Madrid, la propriété système glide.oauth.state.parameter.required rend obligatoire l’utilisation du paramètre state dans les demandes OAuth. La propriété d’état est définie sur vrai par défaut dans les nouvelles instances et est facultative dans les instances mises à niveau. En cas de paramètre d’état manquant, la demande d’autorisation échoue et l’erreur suivante s’affiche : Paramètre d’état manquant dans la demande.
      Clients privés

      Les clients privés (exemple : applications côté serveur) peuvent stocker un secret client en toute sécurité et n’ont pas besoin de PKCE.

      • La demande d’autorisation est lancée en redirigeant l’utilisateur vers le point de terminaison d’autorisation. Aucune contestation du secret client ou du code PKCE n’est requise dans cette étape.
      • Au cours de la demande de jeton, le client inclut le secret client ainsi que le code d’autorisation pour obtenir le jeton d’accès.
      Effectuez une demande GET au point de terminaison d’autorisation avec les paramètres suivants :
      Method: GET
Endpoint: https://<servicenow_base_url>/oauth_auth.do
      Tableau 2. Paramètres de demande d’autorisation (secret du client privé)
      Paramètre Obligatoire Description
      response_type Oui Définissez la valeur sur code pour lancer le flux de code d’autorisation.
      client_id Oui L’identificateur unique pour votre application cliente.

      Format : YOUR_CLIENT_ID
      redirect_uri Oui L’URI auquel ServiceNow envoie le code d’autorisation.

      Exemple : https://yourapp.com/callback
      périmètre Facultatif Une liste de champs d’application demandés séparés par des espaces.

      Exemple : incident_read incident_write.
      État Oui Valeur générée par le client et utilisée pour éviter les attaques de contrefaçon de requête intersite (CSRF). La valeur est renvoyée inchangée dans l’URI de redirection, ce qui permet au client de la valider.
    3. Connectez-vous et donnez votre consentement d’accès à l’application cliente.
      Connectez-vous ServiceNow (ou IdP, si SSO est activé) et donnez votre consentement d’accès à l’application cliente.
    4. ServiceNow (ou IdP, si SSO est activé) valide les informations d’identification et ServiceNow renvoie un code d’autorisation au client.
      Une fois l’authentification réussie, le navigateur est redirigé vers le redirect_uri et le code d’autorisation est inclus dans la chaîne de requête :
      https://yourapp.com/callback?code=AUTH_CODE&state=xyz123
    5. Lancez la demande d’autorisation.

      Le client redirige l’utilisateur vers le point de terminaison d’autorisation ServiceNow pour un jeton d’accès. La méthode d’initiation de la demande d’autorisation dépend du type de client : public ou privé.

      Clients publics

      Les clients publics (exemple : applications mobiles ou à page unique) ne peuvent pas stocker un secret client en toute sécurité. Par conséquent, ils doivent utiliser la clé de preuve pour l’échange de code (PKCE) pour renforcer la sécurité.

      • Dans la demande d’autorisation, incluez la contestation de code PKCE et spécifiez la méthode de contestation de code.
      • Pendant la demande de jeton, le client doit envoyer le vérificateur de code pour valider le code d’autorisation.
      Le client envoie une demande POST au point de terminaison de jeton avec les paramètres suivants :
      
Method: POST  
Endpoint: https://<servicenow_base_url>/oauth_token.do  
Headers: Content-Type: application/x-www-form-urlencoded
      Tableau 3. Paramètres de demande de jeton (Client public-PKCE)
      Paramètre Obligatoire Description
      grant_type Oui Définissez la valeur sur authorization_code pour échanger le code contre un jeton.
      code Oui Le code d’autorisation reçu du point de terminaison d’autorisation.
      redirect_uri Oui L’URI utilisé dans la demande d’autorisation initiale.

      Exemple : https://yourapp.com/callback
      client_id Oui L’identificateur unique pour votre application cliente.
      code_verifier Oui Chaîne d’origine utilisée pour générer le code_challenge PKCE.
      État Oui Une valeur générée par le client utilisée pour aider à prévenir les attaques CSRF. La valeur est renvoyée inchangée dans l’URI de redirection, ce qui permet au client de la valider.
      Clients privés

      Les clients privés (exemple : applications côté serveur) peuvent stocker un secret client en toute sécurité et n’ont pas besoin de PKCE.

      • La demande d’autorisation est lancée en redirigeant l’utilisateur vers le point de terminaison d’autorisation. Aucune contestation du secret client ou du code PKCE n’est requise dans cette étape.
      • Au cours de la demande de jeton, le client inclut le secret client ainsi que le code d’autorisation pour obtenir le jeton d’accès.
      Effectuez une demande POST au point de terminaison d’autorisation avec les paramètres suivants :
      
Method: POST 
Endpoint: https://<servicenow_base_url>/oauth_token.do   
Headers: Content-Type: application/x-www-form-urlencoded
      Tableau 4. Paramètres de demande de jeton (client privé : secret client)
      Paramètre Obligatoire Description
      grant_type Oui Définissez la valeur sur authorization_code pour échanger le code contre un jeton.
      code Oui Le code d’autorisation reçu du point de terminaison d’autorisation.
      redirect_uri Oui L’URI utilisé dans la demande d’autorisation initiale.

      Exemple : https://yourapp.com/callback
      client_id Oui L’identificateur unique pour votre application cliente.
      client_secret Oui Clé secrète du client utilisée pour s’authentifier avec le point de terminaison de jeton.
      État Oui Une valeur générée par le client utilisée pour aider à prévenir les attaques CSRF. La valeur est renvoyée inchangée dans l’URI de redirection, ce qui permet au client de la valider.
    6. Accéder aux API avec le jeton d’accès ServiceNow .
      Exemple :
      Effectuez une demande GET auprès des API à l’aide du jeton d’accès. Incluez le jeton d’accès dans l’en-tête d’autorisation .
      Method: GET
End Point: https://<servicenow_base_url>/api/now/incident  
Authorization: Bearer YOUR_ACCESS_TOKEN
    7. Renouvelez le jeton d’accès s’il a expiré.
      Effectuez une demande POST pour actualiser le jeton d’accès (clients privés uniquement) avec les paramètres suivants :
      
Method: POST  
Endpoint: https://<servicenow_base_url>/oauth_token.do  
Headers: Content-Type: application/x-www-form-urlencoded
      Tableau 5. Paramètres de demande de jeton d’actualisation (client privé)
      Paramètre Obligatoire Description
      grant_type Oui Définissez la valeur sur refresh_token pour demander un nouveau jeton d’accès.
      refresh_token Oui Le jeton d’actualisation précédemment émis par le point de terminaison de jeton.
      client_id Oui L’identificateur unique pour votre application cliente.
      client_secret Oui Clé secrète du client utilisée pour s’authentifier avec le point de terminaison de jeton.