【Keycloak】REST APIでKeycloakを使用する際の「有効なリダイレクトURI(valid redirect uris)」には何を設定すれば良い？

Question

前提・実現したいこと

はじめまして。
Keycloakにて認証/認可を実施するPythonのRESTful APIの作成をしています。
APIの使用用途としては他APIからのリクエストやブラウザからのAjax通信によるリクエストを受けての使用を想定しています。

発生している問題

現在Keycloakのクライアントを作成しているのですが、
クライアントの「アクセスタイプ(Access Type)」を「confidential」に設定した際の項目
**「有効なリダイレクトURI(valid redirect uris)」**に何のURIを設定すれば良いのかが分からず行き詰っています。

項目の？マークをマウスオーバーすると

ログインまたはログイン成功後にブラウザーがリダイレクト可能とする、有効なURIパターンを設定します。

とメッセージが表示されますが、他APIからの利用も想定しているため、「ブラウザがリダイレクト」という点がイマイチ想像できていません。

クライアント・プロトコルは「openid-connect」を設定し、
認証/認可は以下のフローをイメージしています。

①．AシステムがREST APIへリクエストを実施
②．REST APIがKeycloakのエンドポイントにアクセス
③. Keycloakが認証/認可を実施、結果をREST APIへ返却
④. 認証/認可結果後のレスポンス情報をAシステムへ返却

①Aシステム　→　②REST API　→　③Keycloak →　④REST API →　Aシステム

何分SSO関連についての知識が乏しいため、足りない説明、前提設定等あるかもしれませんが、
どなたかご教授いただければ幸いです。

Comments

[etherbeg]

回答というわけではないのと、私もKeycloakの運用経験とかWeb APIの認証周りの実装経験とかあるわけでもなく、OpenID Connectについても浅い知識しかないのとで、こちらに書かせていただきます。

まずKeycloakには日本語のドキュメント（野村総合研究所のオープンソース関連部署が翻訳・公開してくれている）があるので、「項目の？マークをマウスオーバー」するだけじゃなくて、ドキュメントも参考にするといいと思います。
https://keycloak-documentation.openstandia.jp/

クライアントの作成に関してはここですね。
https://keycloak-documentation.openstandia.jp/master/ja_JP/server_admin/#_clients
SSOプロトコル自体についての解説もあります。
https://keycloak-documentation.openstandia.jp/master/ja_JP/server_admin/#sso%E3%83%97%E3%83%AD%E3%83%88%E3%82%B3%E3%83%AB

次にリダイレクトURIについてですが、ここ
https://www.mhlw.go.jp/stf/newpage_14525.html
の「別添資料１　OpenID Foundation の策定規格詳細」のPDFの10ページ（表紙も入れると11ページ）の図が一番分かりやすいかなと。

上から下に向かって処理が進んでいて、2回リダイレクトが出てきますが、2つ目のリダイレクト、「リダイレクトURI」っていうフキダシがついているリダイレクトのURIが、「有効なリダイレクトURI(valid redirect uris)」に入力するURIです。ここのURIで認可サーバからもらった認可コードを渡して、それと引き換えにアクセストークンとIDトークンをもらいます。

あとここのスライド
https://www.slideshare.net/tkudo/oauth-oidc-api-security-yuzawaws
の30〜31ページに、「クライアントの『リダイレクション・エンドポイント』」についての説明がありますが、この「リダイレクション・エンドポイント」が「リダイレクトURI」のことです。

この2つのPDF／スライドで説明されているフローはOpenID Connectの「認可コードフロー」というフローなわけですが、質問文中の「認証/認可は以下のフローをイメージしています」以下を読むと、本当にこの「認可コードフロー」を想定されているのかな…？ と疑問に感じるところではあります。

[SasakiNozomi]

ご丁寧に文献の提供や解説ありがとうございます。
ご提供頂いた資料より、自身OpenID Connectの認可フローについての認識齟齬が多々あったことに気付かされました。（認可コード≠アクセストークンや非推奨とあるスライドの19ページの構成を想定していた等々）
頂いた資料を落とし込み、再度実装構成を改め、本QAに投稿させていただきます。
取り急ぎの報告ではございますが、非常に助かりました。
繰り返しになりますが、無知な質問に対しても非常にご丁寧な対応をありがとうございました。

[etherbeg]

丁寧なお返事をいただきありがとうございます。色々インターネット上にも資料や解説はあるのですが、それらを統一的に理解するのが難しいですね…。種々の観点からの解説が混在していることや、OAuthとOpenID Connectとで同じことを違う用語で説明していたりすることもそれを難しくしているようです。せっかくいただいた勉強の機会ですので、できればもう少し理解を進めることができれば…と思っています。