引き続き API プラグインについての調査です。
と、云ってもとりあえずは今回で終了になるかと思います。
それではAPIプラグインに内包されている簡易テスト機能の動作確認です。
最終回は「Authorization」側につい見ていきたいと思います。
　
「Authorization」側のテスト機能に関しては基本的に認可状態の確認です。
　
■認証処理
　
　▼【GET】ユーザーの個人情報を取得するエンドポイント
　
　　特に設定値はありません。
　　ログインしているかどうかを判断します。
　　ログインしている場合には「OpenID Connect UserInfo エンドポイント」のユーザーに関する個人情報が取得できます。
　　まぁ、管理者用ログインでテストしても余り情報は取得できません（笑）
　　会員用ログインすると会員情報が取得できるようです。
　
　
　▼【GET】管理者認可用エンドポイント
　▼【POST】管理者認可用エンドポイント
　
　　HTMLにて送信するメソッドが異なることを除き、機能としては同じ状態となります。
　　設定項目としては以下の内容です。
　
　　・client_id【必須】
　　　必須項目となります。
　　　アプリケーション登録をした際に発行された「Client ID」を入力します。
　
　　・redirect_uri【必須】
　　　必須項目となります。
　　　リダイレクト先の URI を指定する必要があります。
　　　今回のテスト環境の場合は指定されている URI を記載する形ですね。
　
　　・response_type【必須】
　　　必須項目となります。
　　　特に何を入力しても良いようです。
　
　　　実際には「code」と云う形で使っています。
　　　後程トークンIDを取得する際に使用する「Authorization code の文字列」が返される形です。　　　
　
　　・state【必須】
　　　必須項目となります。
　　　実際には OAuth2.0 だけを使用する場合、【必須】項目では無くあくまでも【推奨】項目となります。
　　　しかしながら EC-CUBE3 の場合は【必須】の扱いとなります。
　　　少しだけ注意が必要です。
　
　　　内容としてはランダムの値を用いることでセキュリティの向上を目的とします。
　　　一般的に「クロスサイトリクエストフォージェリ」対策の目的で利用されるそうです。
　　　ECサイトを運用する以上、あって損をするものでは無さそうです。
　
　　・scope(必須?)
　　　必須項目ではありません。
　　　一度設定しておけば毎回確認をする必要はないからでしょうか。
　　　実際にはここで設定した内容を元に使用したい処理への認可を行う形となります。
　　　複数設定する場合はスペース区切りとなります。
　
　　・nonce
　　　必須項目ではありません。
　　　内容としては「state」項目と同じでセキュリティの向上を目的とします。
　　　方法もランダムな値を設定する形ですね。
　　　こちらはに「クリプレイアタック」対策の目的で利用されるそうです。
　　　こちらは必須にはならないんですね・・・、判断基準が良く解りません（笑）
　
　　実際には認可要求画面を表示することが目的となります。
　　認可要求が完了した場合には「redirect_uri」に対して「response_type」で指定したパラメーターの値を付与した上でリダイレクトします。
　　今回の一番の使用方法は認可された場合に「Authorization code の文字列」を付与すると云うことですね。
　　後の作業は「Authorization code の文字列」を使用してトークンIDを取得してからになります。
　
　
　▼【GET】会員用可用エンドポイント
　▼【POST】会員認可用エンドポイント
　
　　HTMLにて送信するメソッドが異なることを除き、機能としては同じ状態となります。
　　設定項目は管理者用と項目が同一です。
　　実際の処理は「管理者用」と「会員用」で異なるのかもしれませんが入力する項目自体は同じです。
　
　
　▼【POST】トークン取得用のエンドポイント
　
　　id_token などのトークン情報を取得します。
　　設定項目としては以下の内容です。
　
　　・・・しかしながらこの処理に関してはテストが成功していません。
　　今回のテスト管理画面の設定を考えると「Authorization code の文字列」を取得する認可の際の状況が正常にリダイレクトされないんですね。
　　この部分に関してはテスト環境では無く実際の環境で試した方が良さそうです。
　
　　・Authorization【必須】
　　　必須項目となります。
　　　アプリケーション登録をした際に発行された「Client ID」「Client secret」が必要になります。
　　　テストが成功していない為、真偽は不明です「Client ID:Client secret」の形式でBase64 エンコーディングをする必要がある様です。
　　　例として以下の様な形では無いかと想定しています。
　
　　　Client ID
　　　　⇒　ade9e7376bc84b956d430ce58c28c5144c45ef98
　　　Client secret
　　　　⇒　835caf1550b9260e43e63019aa8ff0ee93b0ed33
　　　記述例
　　　　⇒　ade9e7376bc84b956d430ce58c28c5144c45ef98:WYJYkJJFuOZ56
　
　　・grant_type【必須】
　　　必須項目となります。
　　　認可形式を指定するようです。
　　　実際の認可形式としては幾つかあると思うのですが実際には「authorization_code」しか正常に動作しないように思います。
　　　他の認可形式は「unsupported_grant_type」と表示されてしまう様です。
　
　　・code（必須?）
　　　必須項目ではありません。
　　　実際には認可が完了した際に発行される「Authorization code の文字列」を入力する様です。
　
　　・redirect_uri
　　　必須項目ではありません。
　　　リダイレクト先の URI を指定する様です。
　
　　・refresh_token
　　　必須項目ではありません。
　　　リフレッシュトークンを再利用する際に指定するのでしょうか。
　　　使い道が不明です。
　
　　実際にはトークンレスポンスを返す形になります。
　　おそらく「curl」の形式でテストをすれば正常に動作出来るのかとは思います。
　　まぁ、そこまで動作環境を構築するのも現段階では辛いものがあります。
　　次のテスト項目も含めてこの辺りでAPIモジュールの動作確認は終了しようかと思います。
　
　
　▼【GET】トークン詳細情報取得用のエンドポイント
　
　　トークンの詳細情報を取得します。
　　設定項目は以下の内容です。
　
　　この処理に関してもテストは成功していません。
　　なお、この機能はEC-CUBE独自で実装しているようです。
　　セキュリティ面について念のため確認項目を増やしていると云ったところでしょうか。
　
　　・id_token【必須】
　　　必須項目となります。
　　　取得したトークンIDを指定します。
　
　
　
これでAPIモジュールに関しての調査は終了にしたいと思います。
また、バージョンが代わった際には改めてテストをするかもしれませんが現時点では終了です。
機能としては大変面白い試みの為、ぜひ継続してほしいと思うのですが、今の時点では本番運用を行う事は推奨されていません。
そのため、もう暫く様子を見ていきたいと思います、今後もぜひ頑張って欲しいですね。
・・・ついでを云うと発表された 2.17系にもAPIプラグインが出来ると良いのになぁ～
　
と云うことで今回はここまでとさせて頂きます。