OAuth API ドキュメント

承認コード付与

• 承認リクエスト

• アプリケーションはまず、どの権限を要求しているかを決定し、次にユーザーをブラウザに送信して権限を取得する必要があります。この認証フローを開始するには、以下のように URL を作成し、エンド ユーザーのブラウザをその URL にリダイレクトします。

            GET 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>
          

• 応答タイプ=コード: 期待する応答の種類。認証コードを受信するには、値が必要です コード。これにより、アプリケーションが認可フローを開始していることが認可サーバーに通知されます。
• クライアントID ： OAuth プロバイダーによって提供されるクライアント ID。
• リダイレクト_uri : ユーザーがアプリへのアクセスを許可または禁止したときにリダイレクトされるコールバック URL。
• 範囲: アプリケーションが要求する権限を示す XNUMX つ以上のスペース区切りの文字列。
• 州 ： アプリケーションはランダムな文字列を生成し、それをリクエストに含めます。次に、ユーザーがアプリを承認した後に同じ値が返されることを確認する必要があります。
• ユーザーがアプリへのアクセスを許可すると、ブラウザは指定されたリダイレクト URL にリダイレクトされ、リクエストには次のものが含まれます。 コード および 状態 クエリ文字列内のパラメータ。
• たとえば、ユーザーは次のような URL にリダイレクトされます。

              https://example-app.com/redirect
              ?code=<authorization-code>
              &state=<security_token>
          

• 当学校区の コード アクセストークンと交換できる認証コードです。これは認可サーバーによって生成され、有効期間は比較的短いです。
• 当学校区の 状態 アプリケーションが最初にリクエストに設定したものと同じセキュリティ トークンです。

• トークンリクエスト

• エンド ユーザーがアプリへのアクセスを許可し、認証コードを受け取った場合は、トークン エンドポイントに対して POST リクエストを行うことで、認証コードをアクセス トークンと交換できます。
• 以下は POST リクエストの例です。

              POST 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>
              
              

• ここでは、各リクエストパラメータについて説明します。
• Grant_type=authorization_code : 提供している助成金の種類。これは、アプリケーションが認可コード付与タイプを使用していることを示します。
• コー​​ド ： 前のステップで受け取った認証コードがここに含まれます。
• リダイレクト_uri: 認可リクエストで以前に提供されたものと同じ URI。
• クライアントID ： OAuth プロバイダーによって提供されるクライアント ID。
• client_secret : OAuth プロバイダーによって提供されるクライアント シークレット。
• トークン エンドポイントでは、リクエスト内のすべてのパラメーターが検証され、コードの有効期限が切れていないこと、クライアント ID とシークレットが一致していることが確認されます。リクエストが成功すると、アクセス トークンが生成され、レスポンスで返されます。

              HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store { "access_token":"hkjher92u9eu2u3uihi2eh9293", "token_type":"bearer", "expires_in":3600, "scope":"profile", "id_token":"" }
              

• ここでは、応答で受信した各パラメータの説明を示します。
• アクセストークン ： Userinfo エンドポイントのアクセス トークン。
• トークンの種類: OAuth 2.0 トークン タイプの値。値は次のようにする必要があります 無記名.
• 有効期限: アクセス トークンの有効期限。
• 範囲： アプリケーションが要求する権限を示す 1 つ以上のスペース区切りの文字列。
• id_トークン: ID トークンは、クライアント使用時の認可サーバーによるエンドユーザーの認証に関するクレームと、場合によってはその他の要求されたクレームを含むセキュリティ トークンです。
• リクエストが失敗した場合、レスポンスのステータスは次のようになります。 404の間違ったリクエスト 次の内容になります。

              "error" : "invalid_request", "error_description" : "アプリの開発者向けのエラーの詳細な説明。"
          

• リソースリクエスト

• トークンのリクエストが成功すると、次のメッセージが得られます。 アクセストークン API 経由で保護されたリソースにアクセスするために使用できる応答内。
• ユーザー情報リクエスト: 以下は、Userinfo リクエストの非形成的な例です。

                   GET http://<wp_base_url>/wp-json/moserver/resource
                   Host: server.example.com
                   Authorization: Bearer <access_token>
                

• リソース サーバーはアクセス トークンを検証および検証し、有効期限が切れていないかどうかを確認します。リソース要求が有効な場合、リソース サーバーは、クレームの名前と値のペアのコレクションを含む JSON オブジェクトで表されるクレームを返します。
• 成功したユーザー情報応答:
• UserInfo クレームは、JSON オブジェクトのメンバーとして返されなければなりません。
  
  以下に例を示します。

                { "id": "1"、"username": "abc"、"first_name": "xyz"、"last_name": "example"、"picture": "https://example.com/-kwtzesU/photo .jpg", "電子メール": "abc@example.com", "ロケール": "en",... }
          

暗黙的なコードの許可

• 承認リクエスト

• アプリケーションはまず、どの権限を要求しているかを決定し、次にユーザーをブラウザに送信して権限を取得する必要があります。この暗黙的なフローを開始するには、以下のように URL を形成し、エンド ユーザーのブラウザをその URL にリダイレクトします。

                以上 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>
          

• 応答タイプ=トークン: 期待する応答の種類。これにより、アプリケーションが暗黙的フローを開始していることが認可サーバーに通知されます。この値が code に設定される認可コード フローとの違いに注意してください。
• クライアントID ： OAuth プロバイダーによって提供されるクライアント ID。
• リダイレクト_uri : ユーザーがアプリへのアクセスを許可または禁止したときにリダイレクトされるコールバック URL。
• 範囲: アプリケーションが要求する権限を示す XNUMX つ以上のスペース区切りの文字列。
• 州 ： アプリケーションはランダムな文字列を生成し、それをリクエストに含めます。次に、ユーザーがアプリを承認した後に同じ値が返されることを確認する必要があります。
• ユーザーがアプリへのアクセスを許可すると、ブラウザは指定されたリダイレクト URL にリダイレクトされ、リクエストには次のものが含まれます。 トークン および 状態 クエリ文字列内のパラメータ。
• たとえば、ユーザーは次のようなコールバック URL にリダイレクトされます。

        https://callback-url?
        #access_token=<access_token>
        &token_type=Bearer
        &expires_in=3600
        &scope=<permissions_requesting>
        

• これと認可コード フローの 2 つの大きな違いに注意してください。応答で認可コードの代わりにアクセス トークンが返されるということです。
• その後、クライアントは アクセストークン リソースサーバーから保護されたリソースにアクセスします。
  ここでは、応答で受信した各パラメータの説明を示します。
• アクセストークン ： Userinfo エンドポイントのアクセス トークン。
• トークンの種類: OAuth 2.0 トークン タイプの値。値は次のようにする必要があります 無記名.
• 有効期限: アクセス トークンの有効期限。
• 範囲： アプリケーションが要求する権限を示す 1 つ以上のスペース区切りの文字列。

• リソースリクエスト

• UserInfo エンドポイントは、認証されたエンドユーザーに関するクレームを返す OAuth 2.0 保護リソースです。返された Claim は、Claim の名前と値のペアのコレクションを含む JSON オブジェクトによって表されます。
• ユーザー情報リクエスト: 以下は、Userinfo リクエストの非形成的な例です。

             GET http://<wp_base_url>/wp-json/moserver/resource
             Host: server.example.com
             Authorization: Bearer <access_token>
          

• 成功したユーザー情報応答:
• UserInfo クレームは、JSON オブジェクトのメンバーとして返されなければなりません。
  
  以下に例を示します。

          { "id": "1"、"username": "abc"、"first_name": "xyz"、"last_name": "example"、"picture": "https://example.com/-kwtzesU/photo .jpg", "電子メール": "abc@example.com", "ロケール": "en",... }
          

パスワードの付与

• リソース所有者のパスワード (または「パスワード」) 付与タイプは、アプリが高度に信頼されている場合に主に使用されます。この構成では、ユーザーはリソース サーバーの資格情報 (ユーザー名/パスワード) をクライアント アプリに提供し、クライアント アプリはそれらをアクセス トークン リクエストで送信します。

• トークンリクエスト

• パスワード許可は最も単純な OAuth 許可の 1 つであり、必要なステップは 1 つだけです。アプリケーションは従来のユーザー名とパスワードのログイン フォームを提示してユーザーの資格情報を収集し、サーバーに対して POST リクエストを送信してパスワードをアクセス トークンと交換します。アプリケーションが行う POST リクエストは次の例のようになります。

          POST 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
          

• このリクエストの POST パラメータについては以下で説明します。
• 許可タイプ=パスワード: これにより、サーバーにパスワード付与タイプを使用していることが伝わります。
• ユーザー名= アプリケーションに入力したユーザーのユーザー名
• パスワード= アプリケーションに入力したユーザーのパスワード
• client_id= 開発者が登録時に取得したアプリケーションの公開識別子
• client_secret= OAuth プロバイダーによって提供されるクライアント シークレット。
• トークン エンドポイントでは、リクエスト内のすべてのパラメーターが検証され、コードの有効期限が切れていないこと、クライアント ID とシークレットが一致していることが確認されます。リクエストが成功すると、アクセス トークンが生成され、レスポンスで返されます。

            HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store { "access_token":"hkjher92u9eu2u3uihi2eh9293", "token_type":"bearer", "expires_in":3600, "scope":"profile", "id_token":"" }
              

• その後、クライアントは アクセストークン リソースサーバーから保護されたリソースにアクセスします。
  ここでは、応答で受信した各パラメータの説明を示します。
• アクセストークン ： Userinfo エンドポイントのアクセス トークン。
• トークンの種類: OAuth 2.0 トークン タイプの値。値は次のようにする必要があります 無記名.
• 有効期限: アクセス トークンの有効期限。
• 範囲： アプリケーションが要求する権限を示す 1 つ以上のスペース区切りの文字列。

• リソースリクエスト

• UserInfo エンドポイントは、認証されたエンドユーザーに関するクレームを返す OAuth 2.0 保護リソースです。返された Claim は、Claim の名前と値のペアのコレクションを含む JSON オブジェクトによって表されます。
• ユーザー情報リクエスト: 以下は、Userinfo リクエストの非形成的な例です。

             GET http://<wp_base_url>/wp-json/moserver/resource
             Host: server.example.com
             Authorization: Bearer <access_token>
          

• 成功したユーザー情報応答:
• UserInfo クレームは、JSON オブジェクトのメンバーとして返されなければなりません。
  
  以下に例を示します。

          { "id": "1"、"username": "abc"、"first_name": "xyz"、"last_name": "example"、"picture": "https://example.com/-kwtzesU/photo .jpg", "電子メール": "abc@example.com", "ロケール": "en",... }
          

クライアント資格情報の付与

• クライアント資格情報の付与は、マシン間の認証に使用できます。この付与では、特定のユーザーが承認されるのではなく、資格情報が検証され、汎用の access_token が返されます。

• トークンリクエスト

• アクセス トークンを受信するために、クライアントは次のように、登録された開発者アプリから取得したクライアント ID とクライアント シークレットの値を使用して API 呼び出しを POST 送信します。

          POST 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>
          



• リクエストパラメータ：
• POST リクエストのパラメータについては以下で説明します。
• Grant_type=client_credentials : これにより、クライアント資格情報の付与タイプを使用していることがサーバーに伝えられます。
• client_id= 開発者が登録時に取得したアプリケーションの公開識別子。
• クライアントシークレット: OAuth プロバイダーによって提供されるクライアント シークレット。
• リダイレクト_uri : ユーザーがアプリへのアクセスを許可または禁止したときにリダイレクトされるコールバック URL。
• 範囲: アプリケーションが要求する権限を示す 1 つ以上のスペース区切りの文字列。
• 資格情報が有効な場合、アプリケーションは署名付き JSON Web トークンまたはアクセス トークン、トークンのタイプ (ベアラー)、および有効期限が切れるまでの時間を Unix 時間で受け取ります。
• サンプル応答

        { "アクセストークン"： , "expires_in": 600, "token_type": "ベアラー" }
          

• 応答要素:
• アクセストークン ： Userinfo エンドポイントのアクセス トークン。
• 有効期限が切れる アクセス トークンの有効期限。
• トークンの種類: OAuth 2.0 トークン タイプの値。値は次のようにする必要があります 無記名.

• リソースリクエスト

• 当学校区の クライアント資格情報の付与 サポートしていません。 リソースリクエスト.

リフレッシュトークンの付与

• リフレッシュ トークンを使用すると、アプリケーションはユーザーを再認証することなく、新しいアクセス トークンまたは ID トークンを発行できます。これは、リフレッシュ トークンが取り消されていない限り機能します。

• トークンリクエスト

• トークン要求の応答には、アクセス トークンとリフレッシュ トークンが含まれている必要があります。

            { "access_token": "etMv23....429hiU32Hri", "refresh_token": "GEbRxBN...edjnXbL", "token_type": "Bearer" }
            

• リフレッシュ トークンを使用します。
• 受け取ったリフレッシュ トークンを新しいアクセス トークンと交換するには、次を使用してトークン エンドポイントに POST リクエストを作成します。 Grant_type=リフレッシュトークン 以下のとおりです。

              POST 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>
            

• ここでは、各リクエストパラメータについて説明します。
• Grant_type=refresh_token : これにより、リフレッシュ トークンの付与タイプを使用していることがサーバーに伝えられます。
• client_id= 開発者が登録時に取得したアプリケーションの公開識別子。
• クライアントシークレット: OAuth プロバイダーによって提供されるクライアント シークレット。
• リフレッシュトークン: 使用するリフレッシュトークン。
• 応答には、新しいアクセス トークン、そのタイプ、有効期間 (秒単位)、および付与されたスコープが含まれます。初期トークンのスコープに openid が含まれている場合、新しい ID トークンも応答に含まれます。
• 応答には次のようなパラメータが含まれます。

            { "access_token": "eyJ...MoQ"、"expires_in": 86400、"scope": , "id_token": "eyJ...0NE", "token_type": "ベアラー" }
            

リフレッシュトークンを取り消す

• リフレッシュ トークンには有効期限がないため、侵害された場合に備えて取り消すことができることが重要です。
• リフレッシュ トークンを取り消すには、 POST 次のようにトークンエンドポイントにリクエストします。

            POST 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>
          

無料試用版

探しているものが見つからない場合は、下記までお問い合わせください。 info@miniorange.com またはでお電話 +1 978 658 9387 Wordpress OAuth サーバーに関する質問への回答を見つけるには、