Résultats de recherche :

×
S'inscrire Contactez-Nous

Documentation de l'API OAuth

Octroi de code d'autorisation

  • Demande d'autorisation

    • L'application doit d'abord déterminer les autorisations requises, puis rediriger l'utilisateur vers un navigateur pour obtenir son autorisation. Pour initier ce processus d'autorisation, créez une URL comme ci-dessous et redirigez le navigateur de l'utilisateur final vers cette URL : 
      •             ÉCONOMISEZ http://<wp_base_url>/wp-json/moserver/authorize
            ?response_type=code
            &client_id= <client_id_goes_here>
            &redirect_uri= <callback_url>
            &scope= <permissions_requesting>
            &state= <security_token>
    • réponse_type=code : Le type de réponse attendu. Pour recevoir un code d'autorisation, il doit avoir une valeur. codeCela indique au serveur d'autorisation que l'application initie le flux d'autorisation.
    • identité du client : L'ID client fourni par le fournisseur OAuth.
    • redirect_uri : URL de rappel vers laquelle l'utilisateur sera redirigé une fois qu'il aura autorisé ou refusé l'accès à votre application.
    • portée : Une ou plusieurs chaînes de caractères séparées par des espaces indiquant l'autorisation demandée par votre application.
    • Etat : L'application génère une chaîne de caractères aléatoire et l'inclut dans la requête. Elle doit ensuite vérifier que la même valeur est renvoyée après l'autorisation de l'application par l'utilisateur.
    • Si l'utilisateur autorise l'accès à votre application, son navigateur sera redirigé vers l'URL de redirection fournie et la requête inclura code et Etat paramètres dans la chaîne de requête.
    • Par exemple, l'utilisateur peut être redirigé vers une URL telle que
      •               https://example-app.com/redirect
              ?code=<authorization-code>
              &state=<security_token>
    • Le code Il s'agit d'un code d'autorisation qui peut être échangé contre un jeton d'accès. Ce code est généré par le serveur d'autorisation et a une durée de vie relativement courte.
    • Le Etat il s'agit du même jeton de sécurité que celui initialement défini par l'application dans la requête.

  • Demande de jeton

    • Si l'utilisateur final a accordé l'accès à votre application et que vous recevez un code d'autorisation, vous pouvez échanger ce code contre un jeton d'accès en effectuant une requête POST vers le point de terminaison du jeton.
    • Voici un exemple de requête POST :
      •               POSTEZ http://<wp_base_url>/wp-json/moserver/token
              Content-Type: application/x-www-form-urlencoded
         
              grant_type=authorization_code&
              code=<authorization_code>&
              client_id=<client_id>&
              client_secret=<clientSecret>&
              redirect_uri=<redirect_uri>
    • Voici la description de chaque paramètre de requête.
      • grant_type=autorisation_code : Le type d'autorisation que vous accordez. Cela indique que l'application utilise le type d'autorisation par code.
      • Code: Le code d'autorisation reçu à l'étape précédente est inclus ici.
      • redirect_uri : La même URI que celle fournie précédemment dans la demande d'autorisation.
      • identité du client : L'identifiant client fourni par le fournisseur OAuth.
      • client_secret : Le secret client fourni par le fournisseur OAuth.
    • Au niveau du point de terminaison du jeton, tous les paramètres de la requête seront vérifiés afin de s'assurer que le code n'a pas expiré et que l'identifiant et le secret du client correspondent. Si la requête aboutit, un jeton d'accès sera généré et renvoyé dans la réponse. 
      •               HTTP/1.1 200 OK Type de contenu : application/json Cache-Control : no-store { "access_token": "hkjher92u9eu2u3uihi2eh9293", "token_type": "bearer", "expires_in": 3600, "scope": "profile", "id_token": "" }
    • Voici la description de chaque paramètre reçu dans la réponse.
      • jeton d'accès : jeton d’accès pour le point de terminaison Userinfo.
      • type_jeton : Valeur du type de jeton OAuth 2.0. La valeur doit être porteur.
      • expire dans : L’heure d’expiration du jeton d’accès.
      • portée: Une ou plusieurs chaînes de caractères séparées par des espaces indiquant l'autorisation demandée par votre application.
      • id_token : Le jeton d'identification est un jeton de sécurité qui contient des revendications concernant l'authentification d'un utilisateur final par un serveur d'autorisation lors de l'utilisation d'un client, et potentiellement d'autres revendications demandées.
    • Si la demande échoue, la réponse aura le statut : 404 Bad Request et aura le contenu suivant : 
      •               "error" : "invalid_request", "error_description" : "Une description plus détaillée de l'erreur destinée au développeur de votre application."

  • Demande de ressources

    • Si la demande de jeton réussit, vous obtiendrez jeton d'accès dans la réponse qui peut être utilisée pour accéder aux ressources protégées via l'API.
    • Demande d'informations utilisateur : Voici un exemple non formatif de requête Userinfo : 
      •                    ÉCONOMISEZ http://<wp_base_url>/wp-json/moserver/resource
                   Host: server.example.com
                   Authorization: Bearer <access_token>
    • Le serveur de ressources valide et vérifie le jeton d'accès et s'assure de sa validité. Si la requête est valide, il renvoie les revendications, représentées par un objet JSON contenant une collection de paires nom/valeur.
    • Réponse utilisateur réussie :
    • Les revendications UserInfo DOIVENT être renvoyées en tant que membres d'un objet JSON.

      Ci-dessous l'exemple : 
      •                 { "id": "1", "username": "abc", "first_name": "xyz", "last_name": "example", "picture": "https://example.com/-kwtzesU/photo .jpg", "email": "abc@example.com", "locale": "en",... }

Octroi de code implicite

  • Demande d'autorisation

    • L'application doit d'abord déterminer les autorisations requises, puis rediriger l'utilisateur vers un navigateur pour obtenir son autorisation. Pour initier ce flux implicite, créez une URL comme ci-dessous et redirigez le navigateur de l'utilisateur final vers cette URL : 
      •               Prendre http://<wp_base_url>/wp-json/moserver/authorize 
              ?response_type=token
              &client_id= <client_id_goes_here>
              &redirect_uri= <callback_url>
              &scope= <permissions_requesting>
              &state= <security_token>
    • réponse_type=jeton : Type de réponse attendue. Ce paramètre indique au serveur d'autorisation que l'application initie un flux implicite. Notez la différence avec le flux d'autorisation par code, où cette valeur est définie sur « code ».
    • identité du client : L'ID client fourni par le fournisseur OAuth.
    • redirect_uri : URL de rappel vers laquelle l'utilisateur sera redirigé une fois qu'il aura autorisé ou refusé l'accès à votre application.
    • portée : Une ou plusieurs chaînes de caractères séparées par des espaces indiquant l'autorisation demandée par votre application.
    • Etat : L'application génère une chaîne de caractères aléatoire et l'inclut dans la requête. Elle doit ensuite vérifier que la même valeur est renvoyée après l'autorisation de l'application par l'utilisateur.
    • Si l'utilisateur autorise l'accès à votre application, son navigateur sera redirigé vers l'URL de redirection fournie et la requête inclura jeton et Etat paramètres dans la chaîne de requête.
    • Par exemple, l'utilisateur peut être redirigé vers une URL de rappel telle que 
      •         https://callback-url?
        #access_token=<access_token>
        &token_type=Bearer
        &expires_in=3600
        &scope=<permissions_requesting>
    • Notez les deux principales différences entre ce flux et celui du code d'autorisation : le jeton d'accès est renvoyé au lieu du code d'autorisation dans la réponse.
    • Le client peut alors utiliser le jeton d'accès pour accéder aux ressources protégées du serveur de ressources.
      Voici la description de chaque paramètre reçu dans la réponse.
      • jeton d'accès : jeton d’accès pour le point de terminaison Userinfo.
      • type_jeton : Valeur du type de jeton OAuth 2.0. La valeur doit être porteur.
      • expire dans : L’heure d’expiration du jeton d’accès.
      • portée: Une ou plusieurs chaînes de caractères séparées par des espaces indiquant l'autorisation demandée par votre application.

  • Demande de ressources

    • Le point de terminaison UserInfo est une ressource protégée OAuth 2.0 qui renvoie des revendications concernant l'utilisateur final authentifié. Ces revendications sont représentées par un objet JSON contenant une collection de paires nom/valeur.
    • Demande d'informations utilisateur : Voici un exemple non formatif de requête Userinfo : 
      •              ÉCONOMISEZ http://<wp_base_url>/wp-json/moserver/resource
             Host: server.example.com
             Authorization: Bearer <access_token>
    • Réponse utilisateur réussie :
    • Les revendications UserInfo DOIVENT être renvoyées en tant que membres d'un objet JSON.

      Ci-dessous l'exemple : 
      •           { "id": "1", "username": "abc", "first_name": "xyz", "last_name": "example", "picture": "https://example.com/-kwtzesU/photo .jpg", "email": "abc@example.com", "locale": "en",... }

Octroi de mot de passe

  • L'autorisation par mot de passe du propriétaire de la ressource est principalement utilisée lorsque l'application est considérée comme hautement fiable. Dans cette configuration, l'utilisateur fournit ses identifiants de connexion au serveur de ressources (nom d'utilisateur et mot de passe) à l'application cliente, qui les transmet dans une requête de jeton d'accès.

  • Demande de jeton

    • L'autorisation par mot de passe est l'une des autorisations OAuth les plus simples et ne comporte qu'une seule étape : l'application présente un formulaire de connexion classique (nom d'utilisateur et mot de passe) pour recueillir les identifiants de l'utilisateur et envoie une requête POST au serveur afin d'échanger le mot de passe contre un jeton d'accès. La requête POST envoyée par l'application ressemble à l'exemple ci-dessous. 
      •           POSTEZ http://<wp_base_url>/wp-json/moserver/token
          Host: authorization-server.com
          Content-type: application/x-www-form-urlencoded
  
          grant_type=password
          &username=exampleuser
          &password=12345678
          &client_id=xxxxxxxxxx
          &client_secret=xxxxxxxxxx
    • Les paramètres POST de cette requête sont expliqués ci-dessous.
      • grant_type=mot de passe : Cela indique au serveur que nous utilisons le type d'autorisation par mot de passe.
      • nom d'utilisateur = Le nom d'utilisateur que l'utilisateur a saisi dans l'application
      • password = Le mot de passe que l'utilisateur a saisi dans l'application
      • identifiant_client= L'identifiant public de l'application que le développeur a obtenu lors de l'enregistrement.
      • client_secret= Le secret client fourni par le fournisseur OAuth.
    • Au niveau du point de terminaison du jeton, tous les paramètres de la requête seront vérifiés afin de s'assurer que le code n'a pas expiré et que l'identifiant et le secret du client correspondent. Si la requête aboutit, un jeton d'accès sera généré et renvoyé dans la réponse. 
      •             HTTP/1.1 200 OK Type de contenu : application/json Cache-Control : no-store { "access_token": "hkjher92u9eu2u3uihi2eh9293", "token_type": "bearer", "expires_in": 3600, "scope": "profile", "id_token": "" }
    • Le client peut alors utiliser le jeton d'accès pour accéder aux ressources protégées du serveur de ressources.
      Voici la description de chaque paramètre reçu dans la réponse.
      • jeton d'accès : jeton d’accès pour le point de terminaison Userinfo.
      • type_jeton : Valeur du type de jeton OAuth 2.0. La valeur doit être porteur.
      • expire dans : L’heure d’expiration du jeton d’accès.
      • portée: Une ou plusieurs chaînes de caractères séparées par des espaces indiquant l'autorisation demandée par votre application.

  • Demande de ressources

    • Le point de terminaison UserInfo est une ressource protégée OAuth 2.0 qui renvoie des revendications concernant l'utilisateur final authentifié. Ces revendications sont représentées par un objet JSON contenant une collection de paires nom/valeur.
    • Demande d'informations utilisateur : Voici un exemple non formatif de requête Userinfo : 
      •              ÉCONOMISEZ http://<wp_base_url>/wp-json/moserver/resource
             Host: server.example.com
             Authorization: Bearer <access_token>
    • Réponse utilisateur réussie :
    • Les revendications UserInfo DOIVENT être renvoyées en tant que membres d'un objet JSON.

      Ci-dessous l'exemple : 
      •           { "id": "1", "username": "abc", "first_name": "xyz", "last_name": "example", "picture": "https://example.com/-kwtzesU/photo .jpg", "email": "abc@example.com", "locale": "en",... }

Subvention des informations d'identification des clients

  • L'autorisation par informations d'identification du client peut être utilisée pour l'authentification machine à machine. Dans ce cas, aucun utilisateur spécifique n'est autorisé ; ce sont plutôt les informations d'identification qui sont vérifiées et un jeton d'accès générique qui est renvoyé.

  • Demande de jeton

    • Pour recevoir un jeton d'accès, le client effectue un appel API POST avec les valeurs d'ID client et de secret client obtenues à partir d'une application de développeur enregistrée, comme suit. 
      •           POSTEZ http://<wp_base_url>/wp-json/moserver/token
              Content-Type: application/x-www-form-urlencoded
         
              grant_type=client_credentials&
              client_id=<client_id>&
              client_secret=<clientSecret>&
              redirect_uri=<redirect_uri>&
              scope=<permisssions_requested>

    • Paramètres de demande :
      • Les paramètres de la requête POST sont expliqués ci-dessous.
      • grant_type=client_credentials : Cela indique au serveur que nous utilisons le type d'autorisation basé sur les informations d'identification du client.
      • identifiant_client= L'identifiant public de l'application que le développeur a obtenu lors de l'enregistrement.
      • client_secret : Le secret client fourni par le fournisseur OAuth.
      • redirect_uri : URL de rappel vers laquelle l'utilisateur sera redirigé une fois qu'il aura autorisé ou refusé l'accès à votre application.
      • portée : Une ou plusieurs chaînes de caractères séparées par des espaces indiquant l'autorisation demandée par votre application.
    • Si les informations d'identification sont valides, l'application recevra en retour un jeton Web JSON signé ou un jeton d'accès, le type du jeton (qui est Bearer) et sa durée de validité en temps Unix.
    • Exemple de réponse
      •         { "jeton d'accès": , "expires_in": 600, "token_type": "Porteur" }
    • Éléments de réponse :
      • jeton d'accès : jeton d’accès pour le point de terminaison Userinfo.
      • expire dans L’heure d’expiration du jeton d’accès.
      • type_de jeton : Valeur du type de jeton OAuth 2.0. La valeur doit être porteur.

  • Demande de ressources

    • Le Subvention des informations d'identification des clients ne supporte pas Demande de ressources.

    Actualiser l'octroi de jetons

    • Un jeton d'actualisation permet à l'application d'émettre un nouveau jeton d'accès ou jeton d'identification sans avoir à réauthentifier l'utilisateur. Cela reste possible tant que le jeton d'actualisation n'a pas été révoqué.

    • Demande de jeton

      • La réponse à la requête de jeton doit contenir un jeton d'accès et un jeton d'actualisation. 
        •             { "access_token": "etMv23....429hiU32Hri", "refresh_token": "GEbRxBN...edjnXbL", "token_type": "Bearer" }
      • Utilisez un jeton d'actualisation :
      • Pour échanger le jeton d'actualisation que vous avez reçu contre un nouveau jeton d'accès, effectuez une requête POST au point de terminaison du jeton, en utilisant grant_type=refresh_token comme suit. 
        •               POSTEZ http://<wp_base_url>/wp-json/moserver/token
              Content-Type: application/x-www-form-urlencoded
              grant_type=refresh_token&
              client_id=<client_id>&
              client_secret=<client_secret>&
              refresh_token=<refresh_token>
      • Voici la description de chaque paramètre de requête.
        • grant_type=refresh_token : Cela indique au serveur que nous utilisons le type d'autorisation de jeton d'actualisation.
        • identifiant_client= L'identifiant public de l'application que le développeur a obtenu lors de l'enregistrement.
        • client_secret : Le secret client fourni par le fournisseur OAuth.
        • rafraîchir_token : Le jeton d’actualisation à utiliser.
      • La réponse inclura un nouveau jeton d'accès, son type, sa durée de vie (en secondes) et les autorisations accordées. Si l'autorisation du jeton initial incluait openid, un nouveau jeton d'identification sera également inclus dans la réponse.
      • La réponse contiendra les paramètres suivants :
        •             { "access_token": "eyJ...MoQ", "expires_in": 86400, "scope": , "id_token": "eyJ...0NE", "token_type": "Porteur" }

    Révoquer un jeton d'actualisation

    • Étant donné que les jetons d'actualisation n'expirent jamais, il est essentiel de pouvoir les révoquer s'ils sont compromis.
    • Pour révoquer un jeton d'actualisation, vous pouvez envoyer un POSTEZ requête au point de terminaison du jeton comme suit. 
      •             POSTEZ http://<wp_base_url>/wp-json/moserver/token
            Content-Type: application/x-www-form-urlencoded
            client_id=<client_id>&
            client_secret=<client_secret>&
            refresh_token=<refresh_token>

Essai gratuit

Si vous ne trouvez pas ce que vous cherchez, veuillez nous contacter à info@miniorange.com ou nous appeler au +1 978 658 9387 pour obtenir une réponse à votre question concernant le serveur OAuth de WordPress.

Regardez les vidéos pour en savoir plus  Voir la démo
Bonjour!

Besoin d'aide? Nous sommes ici !

soutenez