Documentation de l'API OAuth

Octroi de code d'autorisation

• Demande d'autorisation

• L'application doit d'abord décider quelles autorisations elle demande, puis envoyer l'utilisateur vers un navigateur pour obtenir son autorisation. Pour lancer ce flux d'autorisation, créez une URL comme ci-dessous et redirigez le navigateur de l'utilisateur final vers l'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 que vous attendez. Pour recevoir le code d'autorisation, il doit avoir une valeur code. Cela indique au serveur d'autorisation que l'application lance 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 séparées par des espaces qui indiquent l'autorisation demandée par votre application.
• Etat : L'application génère une chaîne aléatoire et l'inclut dans la requête. Il doit ensuite vérifier que la même valeur est renvoyée une fois que l'utilisateur a autorisé l'application.
• Si l'utilisateur autorise l'accès à votre application, son navigateur sera redirigé vers l'URL de redirection fournie et la demande inclura code ainsi que les 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>
          

• Les code est un code d'autorisation qui peut être échangé contre un jeton d'accès. Il est généré par le serveur d'autorisation et est de relativement courte durée.
• Les Etat est le 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 le code d'autorisation contre un jeton d'accès en envoyant une requête POST au 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 de subvention que vous accordez. Cela indique que l'application utilise le type d'attribution de code d'autorisation.
• Code: Le code d'autorisation reçu à l'étape précédente, inclus ici.
• redirect_uri : Le même uri qui a été fourni plus tôt dans la demande d’autorisation.
• identité du client : L'ID client fourni par le fournisseur OAuth.
• client_secret : Le secret client fourni par le fournisseur OAuth.
• Au point final du jeton, tous les paramètres de la demande seront vérifiés pour garantir que le code n'a pas expiré et que l'identifiant client et le secret correspondent. Si la requête réussit, elle générera un jeton d'accès et le renverra 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 séparées par des espaces qui indiquent l'autorisation demandée par votre application.
• id_token : Le jeton d'identification est un jeton de sécurité qui contient des réclamations concernant l'authentification d'un utilisateur final par un serveur d'autorisation lors de l'utilisation d'un client, et potentiellement d'autres réclamations 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 : Ce qui suit est un exemple non formatif de demande d'informations utilisateur :

                   É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 vérifie s'il n'a pas expiré. Si la demande de ressource est valide, le serveur de ressources renvoie les revendications qui sont représentées par un objet JSON contenant une collection de paires nom et valeur pour les revendications.
• 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écider quelles autorisations elle demande, puis envoyer l'utilisateur vers un navigateur pour obtenir son autorisation. Pour lancer ce flux implicite, créez une URL comme ci-dessous et redirigez le navigateur de l'utilisateur final vers l'URL :

              Obtenez 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 : Le type de réponse que vous attendez. Cela indique au serveur d'autorisation que l'application lance un flux implicite. Notez la différence avec le flux Code d’autorisation 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 séparées par des espaces qui indiquent l'autorisation demandée par votre application.
• Etat : L'application génère une chaîne aléatoire et l'inclut dans la requête. Il doit ensuite vérifier que la même valeur est renvoyée une fois que l'utilisateur a autorisé l'application.
• Si l'utilisateur autorise l'accès à votre application, son navigateur sera redirigé vers l'URL de redirection fournie et la demande inclura jeton ainsi que les 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 différences majeures entre ce flux et le flux de code d'autorisation : le jeton d'accès est renvoyé à la place 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 à partir 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 séparées par des espaces qui indiquent 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é. Les revendications renvoyées sont représentées par un objet JSON qui contient une collection de paires nom et valeur pour les revendications.
• Demande d'informations utilisateur : Ce qui suit est un exemple non formatif de demande d'informations utilisateur :

             É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

• Le type d'attribution du mot de passe du propriétaire de la ressource (ou « mot de passe ») est principalement utilisé dans les cas où l'application est hautement fiable. Dans cette configuration, l'utilisateur fournit ses informations d'identification du serveur de ressources (nom d'utilisateur/mot de passe) à l'application client, qui les envoie dans une demande de jeton d'accès.

• Demande de jeton

• L'octroi de mot de passe est l'une des attributions OAuth les plus simples et ne comporte qu'une seule étape : l'application présente un formulaire de connexion traditionnel avec nom d'utilisateur et mot de passe pour collecter les informations d'identification de l'utilisateur et envoie une requête POST au serveur pour échanger le mot de passe contre un jeton d'accès. La requête POST effectué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'attribution de mot de passe.
• nom d'utilisateur = Le nom d'utilisateur de l'utilisateur qu'il a saisi dans l'application
• password = Le mot de passe de l'utilisateur qu'il a saisi dans l'application
• identifiant_client= L'identifiant public de l'application que le développeur a obtenu lors de l'inscription
• client_secret= Le secret client fourni par le fournisseur OAuth.
• Au point final du jeton, tous les paramètres de la demande seront vérifiés pour garantir que le code n'a pas expiré et que l'identifiant client et le secret correspondent. Si la requête réussit, elle générera un jeton d'accès et le renverra 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 à partir 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 séparées par des espaces qui indiquent 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é. Les revendications renvoyées sont représentées par un objet JSON qui contient une collection de paires nom et valeur pour les revendications.
• Demande d'informations utilisateur : Ce qui suit est un exemple non formatif de demande d'informations utilisateur :

             É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’octroi d’informations d’identification client peut être utilisé pour l’authentification machine à machine. Dans cette subvention, un utilisateur spécifique n'est pas autorisé, mais les informations d'identification sont vérifiées et un access_token générique est renvoyé.

• Demande de jeton

• Pour recevoir un jeton d'accès, le client POST un appel API 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'attribution d'informations d'identification client.
• identifiant_client= L'identifiant public de l'application que le développeur a obtenu lors de l'inscription.
• 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 séparées par des espaces qui indiquent l'autorisation demandée par votre application.
• Si les informations d'identification sont valides, l'application recevra en retour un jeton Web JSON ou un jeton d'accès signé, le type du jeton (qui est Bearer) et le délai d'expiration à l'heure 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

• Les 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 un nouveau jeton d'identification sans avoir à réauthentifier l'utilisateur. Cela fonctionnera tant que le jeton d'actualisation n'a pas été révoqué.

• Demande de jeton

• La réponse à la demande 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'octroi de jeton d'actualisation.
• identifiant_client= L'identifiant public de l'application que le développeur a obtenu lors de l'inscription.
• 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 étendues accordées. Si la portée du jeton initial incluait openid, alors un nouveau jeton d'identification sera également 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 au cas où ils seraient compromis.
• Pour révoquer un jeton d'actualisation, vous pouvez envoyer un POSTEZ demande 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 au info@miniorange.com ou appelez-nous au Tel: +1 (978)658 9387 pour trouver une réponse à votre question sur Wordpress OAuth Server.