action フィールドが含まれます。Authlete を用いた認可サーバー実装の原則はシンプルです。Core API を呼び出し、レスポンスをパースし、action の値を確認して、その値に応じた処理を行います。
アクションのセットは Core API ごとに定義されていますが、その値は 2 つのパターンに分かれます。クライアントへの HTTP レスポンスに直接対応するアクションと、2 つ目の Authlete API 呼び出しが必要なアクションです。
このページでは /auth/authorization API のアクションを例にモデルの動作を説明し、続いて他の Core API で登場する代表的なアクションを紹介します。このページに挙げるのは代表例であり網羅的なリストではないため、呼び出す API の API リファレンスを必ず確認してください。
/auth/authorization のアクション
/auth/authorization API のレスポンスのaction フィールドには、次のいずれかの値が含まれます。
レスポンスには
action のほかに、クライアントの表示情報や要求されたスコープ・クレームなど、認可サーバーが認証・同意画面を組み立てるために必要な情報も含まれます。レスポンスの完全なスキーマは API リファレンスを参照してください。
アクションと HTTP レスポンスの対応
多くのアクションは、クライアントへ返す 1 つの HTTP レスポンスに直接対応します。認可サーバーはresponseContent をそのレスポンスの本体やヘッダーに使います。
たとえば、Authlete Core API からの応答の action が BAD_REQUEST の場合、認可サーバーは次のようなレスポンスをクライアントに返します。
action が LOCATION の場合は次のとおりです。
追加のステップが必要なアクション
INTERACTION と NO_INTERACTION、そして PASSWORD・TOKEN_EXCHANGE・JWT_BEARER のようなグラント処理系のアクションは、1 つの HTTP レスポンスを返すだけでは処理を完了できません。ユーザーの認証や同意の取得などサーバー自身の処理を行ったうえで、2 つ目の Authlete API を呼び出して処理を完了する必要があります。このパターンは2 段階の API 呼び出しで説明します。
他の API の代表的なアクション
他の Core API も、それぞれ固有のアクションセットで同じ規約に従います。次に挙げるのは代表的なアクションであり、網羅的なリストではありません。新しい世代の API（
/vci/*、/gm など）では、エラーの発生箇所を区別します。CALLER_ERROR は実装側のリクエスト誤りを、AUTHLETE_ERROR は Authlete 内部のエラーを意味します。