内容

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 サーバーに関する質問への回答を見つけるには、

詳細についてはビデオをご覧ください デモ

内容

OAuth API ドキュメント

承認コード付与

承認リクエスト

トークンリクエスト

リソースリクエスト

暗黙的なコードの許可

承認リクエスト

リソースリクエスト

パスワードの付与

トークンリクエスト

リソースリクエスト

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

トークンリクエスト

リソースリクエスト

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

トークンリクエスト

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

STAY CONNECTED

プロダクト

ソリューション

なぜミニオレンジなのか

会社概要

内容

OAuth API ドキュメント

承認コード付与

承認リクエスト

トークンリクエスト

リソースリクエスト

暗黙的なコードの許可

承認リクエスト

リソースリクエスト

パスワードの付与

トークンリクエスト

リソースリクエスト

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

トークンリクエスト

リソースリクエスト

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

トークンリクエスト

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

STAY CONNECTED

プロダクト

ソリューション

なぜミニオレンジなのか

会社概要

クッキーの設定

クッキーの同意

Strictly Necessary Cookies

常にアクティブ

パフォーマンスクッキー

常にアクティブ