前回の投稿の続きですが、マイクロサービスやクラウドネイティブ開発が浸透して、クラウドインテグレーションっぽい雰囲気が出て来ると、
「サービスＡが１回の認証で、サービスＡのアクセス許可を得つつ、サービスＢも利用したい。」
とか、そう言う話が出てきます。これをOAuth2 / OIDCの知識を持ってブレークダウンして行くと、
「既存のWebサービスAから、追加したWebサービスBのWebAPIを使用したい（若しくは、その逆）。」
みたいな感じになるかと思います。
...コレ（WebAPIの利用）は、認証と言うより、認可（アクセス制御）の話になりますが、通常、OAuth2 / OIDC の AuthZ / AuthN側では、認証 / 認可リクエストにスコープ ＋ 認可画面を使用してアクセス制御することはできますが、エンタープライズ・システム向けの仕様で、これは、あまり適合しないと思います。
...と言うのも、エンタープライズ・システムでは、基本的にSSO機構（自動再認証の認証機構）としてOAuth2 / OIDCを導入しているケースが多いと思うので、認可機構としては採用されていないのが現実なのだと思います。
これを、端的に表現すると
「AuthZ / AuthN側は、認証専用なので、許可されたクライアント（Client）であれば、主体（Subject）がログインできれば、トークン発行する仕組み。」
と言った感じでしょうか？
こう言う状態で、どうやって、前述の要件である
「追加したWebサービスBから、既存のWebサービスAのWebAPIを使用したい。」
を実現するか？
という話ですが、
「Resource Serverや、APIゲートウェイ上で、トークンのチェック処理をカスタムできれば可能。」
と思います。
具体的には、
Clientは、トークン中の、client_id ＝ aud（Clientを意味する）を、自分に対して発行されたものかどうか？チェックして認証し、また、アクセス制御があるならsub（subjectを意味する）も、当該Client上の処理に関する権限があるか？をチェックして認可する。
Resource Serverで、トークン中の、client_id ＝ aud（Clientを意味する）を、当該Resource Server上の処理に関する権限があるか？チェックして認証し、また、アクセス制御があるならsub（subjectを意味する）も当該Resource Server上の処理に関する権限があるか？をチェックして認可する。
※ ココでは、トークン（access_token）は、JWT（JWS）化してある前提。署名により改ざんできないため、Clientでの検証は、Resource Serverでの検証の前提とはならない。
と言った感じでしょうか？
また、これには、Resource ServerがサポートするClientであるか？や、Resource ServerやClient上で権限を持つSubjectであるか？をチェックする拡張のエンドポイントが追加で必要になるかと思います。
トップページ
お知らせ
開発基盤部会
クラウドネイティブ開発の浸透と、トークン・チェックのカスタマイズ
