実践 KeycloakとAdvanced な機能の紹介 OSSセキュリティ技術の会　第11回勉強会 行こう、アクセス管理からIDガバナンス＆管理へ…の巻 Hiroyuki Wada / @wadahiro 

● NRI OpenStandiaでOSSのサポート、システム構築、技術コンサルティ ングなどに従事 ● OSSの中でも、IAM系のプロダクトに軸足を置いて活動 (Keycloak、midPointなど) ● OSSのコントリビューション活動、翻訳などのコミュニティ活動を実施 自己紹介 

● 「実践 Keycloak」のみどころの1つである、「Webアプリケーションのセ キュリティー保護」について紹介 （書籍の6章の一部） ● 書籍ではちらっとしか登場しないIDレス認証について紹介 今日の内容 

Webアプリケーションの セキュリティー保護 

● 内部アプリケーションと外部アプリケーション ● Webアプリケーションのセキュリティー保護 ● ネイティブアプリケーションとモバイルアプリケーションのセキュリティー保 護 ● REST APIとサービスのセキュリティー保護 6章 さまざまなタイプのアプリケーションの セキュリティー保護 本日はここについて紹介 

1. Webアプリケーションが従来型 or SPA？ 2. SPAなら、呼び出すREST APIが同一 or 外部ドメイン？ 3. 外部ドメインのREST APIを呼ぶなら、仲介APIを経由 or 直接通信？ どのアーキテクチャに合致するかを判断する 1. サーバーサイドWebアプリケーション 2. 専用REST APIを使用するSPA 3. 仲介REST APIを使用するSPA 4. 外部REST APIを使用するSPA Webアプリケーションのアーキテクチャを考慮してセ キュリティー保護のアプローチを決定する 

● PKCEを用いた認可コードフローを利用する （リソースオーナーパスワードクレデンシャルズグラントは使わない） ● Keyclaokのログイン画面を利用し、リダイレクトを利用する （iframeとして埋め込まない） すべてのアーキテクチャに共通する点 

1. サーバーサイドWebアプリケーション ● ベーシックなパターン ● Webアプリケーションはコンフィデン シャルクライアントとなる ● OIDCではなくSAMLを使用することも 可能 ● OIDCであれば、アクセストークンを 利用してユーザーの認証コンテキス トでWebアプリケーションから外部の REST APIを呼び出すことも可能 出所： 実践 Keycloak ( https://www.oreilly.co.jp/books/9784814400096/ ) 

2. 専用REST APIを使用するSPAのセキュリティー保護 ● SPAが同じドメイン上の専用のREST APIを使用するパターン ● 専用REST APIはコンフィデンシャル クライアントとなる ● SPAと専用REST API間の呼び出しに はセッションCookieを利用 出所： 実践 Keycloak ( https://www.oreilly.co.jp/books/9784814400096/ ) 

3. 仲介REST APIを使用するSPAのセキュリティー保護 ● SPAから外部（別ドメイン）のREST APIを、仲介REST APIを経由して呼 び出すパターン (いわゆる、BFFパターン） ● 仲介REST APIはコンフィデンシャル クライアントとなる ● SPAと仲介REST API間の呼び出しに はセッションCookieを利用 ● 仲介REST APIと外部REST API間の 呼び出しにはアクセストークンを利 用 出所： 実践 Keycloak ( https://www.oreilly.co.jp/books/9784814400096/ ) 

4. 外部REST APIを使用するSPAのセキュリティー保護 ● SPAから外部（別ドメイン）のREST APIを直接出すパターン ● SPAはパブリッククライアントとなる ● リフレッシュトークン/アクセストーク ンがブラウザーに渡るため安全性が低 い ● リフレッシュトークンローテーション などのテクニックで安全性を確保 出所： 実践 Keycloak ( https://www.oreilly.co.jp/books/9784814400096/ ) 書籍では12章で解説 

● SPAからアクセストークンを直接使いREST API呼び出す方がアプリケーション 全体としてはシンプルになる (=保守コスト削減) ○ 外部REST APIを呼び出すためだけの仲介サービスは不要 ○ セッションCookieを使うことで気にしないといけない点を考えなくてよい ● 一方で、トークン漏洩によるセキュリティーリスクはある ○ トークン格納先論争 (In-Memory vs Local/SessionStroage vs WebWorker) があるが、いずれにせよXSSに対しては漏洩の危険性がある ● 結局のところ、どれを採用するかはセキュリティーと利便性やコストとのトレード オフを考慮した上で、決定する必要あり どのアプローチにするか FAPI 1.0 Part2 だと パブリッククライアントは禁止 

IDレス認証 

● WebAuthnのセキュリティーキー/認証器にユーザ情報も合わせて保存 することで、ログインIDの入力も省いた認証を可能に ※WebAuthnでは元々Resident Keyという名前だったが Discoverable Credentialという名前に変更されている ● Keycloak v18.0.0から利用可能 ● 公式ガイド内では「Loginless」と表現されているので注意 ● 今後は「Passkey」という名前で広がりそう IDレス認証とは 

「WebAuthn Passwordless Policy」にて 以下を設定 ● Require Resident Key： Yes ● User Verification Requirement： required 

認証フローを設定 ● 「WebAuthn Passwordless Authenticator」を追加する ※Cookie AuthenticatorはSSOしたい場合は必要 

デモ デモ 

● 通常のログインIDを利用した認証との両立はどうする？ 気になるところ ログインID/パスワードを入力できない ... 

WebAuthnで認証 OR パスワードで認証 を定義 1. 認証フローで工夫 ログインID/パスワード認証のAuthenticatorをORで追加 

ログイン完了 ログインID/パスワード認証画面の方 が優先されて初期表示される 辿り着くまで面倒... モーダルで選択 

ログイン完了 2. カスタムAuthenticatorで対応 セキュリティキーになれていない ユーザには分かりにくい？ 

ログイン完了 3. カスタムAuthenticatorでConditional UI対応 ※Conditional UIについては、一昨日に開催された「 #idcon vol.29」 　の発表を見るとよいです https://idcon.connpass.com/event/258685/ iOS16の場合 Chrome 107 (featureフラグ ON) の場合 

デモ デモ 

● 「実践 Keycloak」のみどころの1つとして、6章より「Webアプリケーション のセキュリティー保護」を紹介 ○ OIDC/OAuth2のよくある解説では余り触れられていない、 Webアプリケーションの アーキテクチャを考慮した方式について紹介 ○ 書籍では他にも、ネイティブ/モバイルアプリやREST APIのセキュリティー保護につ いても説明しています ● WebAuthnを利用した「IDレス認証」の方法、今後の普及 が期待されるConditional UIなどについてデモを交えて紹介 ※デモで利用したカスタム Authenticatorの実装例は以下のGitHubで公開しています 　https://github.com/wadahiro/keycloak-webauthn-conditional-ui まとめ