AWSで作るセキュアな認証基盤with OAuth mTLS / Secure Authentication Infrastructure with OAuth mTLS on AWS

2025/04/15
JAWS-UG東京 AWS Community Builders Night
https://jawsug.connpass.com/event/348745/

AWSで作るセキュアな認証基盤with OAuth mTLS

高井 真人
ソフトウェアエンジニア、とか

Transcript

1. AWSで作るセキュアな認証基盤 with OAuth mTLS 株式会社カミナシ 高井 真人（@manaty0226） JAWS-UG東京 AWS Community Builders Night
2. 自己紹介 高井 真人 X ：@manaty0226 GitHub ：@manaty226 Zenn ：@manaty226 株式会社カミナシでID管理・認証基盤を作っています。 2025年にセキュリティカテゴリでCBに初選出。 普段はOAuth関連のRFCを読んで実装したりしています。 無線通信（誤り訂正符号）の研究で博士号を取得したので そちら方面の話も好きです。
3. どんな領域を専門としているか 認証 認可 認証方式 ID連携プロトコル 権限委譲プロトコル アクセス制御 セキュリティにも色々ありますが、認証認可を専門としています。 パスワード認証 TOTP/HOTP パスキー OpenID Connect SAML OAuth 2.x RBAC/ABAC/ReBAC User Managed Access AuthZEN Protocol
4. どんな領域を専門としているか 認証 認可 認証方式 ID連携プロトコル 権限委譲プロトコル アクセス制御 セキュリティにも色々ありますが、認証認可を専門としています。 パスワード認証 TOTP/HOTP パスキー OpenID Connect SAML OAuth 2.x RBAC/ABAC/ReBAC User Managed Access AuthZEN Protocol
5. OpenID ConnectやOAuth 2の仕様概観 OAuth 2.x OpenID Connect JWx関連 RFC 6749 OAuth 2.0 Authorization Framework OpenID Connect Core 1.0 RFC 7519 Json Web Token (JWT) RFC 7516 Json Web Encryption RFC 7515 Json Web Signiture RFC 7518 Json Web Algorithm ベストプラクティス RFC 6819 Threat Model and Security Considerations RFC 9700 Best Current Practice for OAuth 2.0 Security RFC draft OAuth 2.0 for Browser-Based Apps 管理エンドポイント RFC 7591, 7592 Dynamic Client Registration RFC 7009 Token Revocation RFC 7662 Token Introspection グラントタイプ拡張 RFC 8693 Token Exchange RFC 8725 Json Web Token Best Current Practicies RFC 8628 Device Authorization RFC 7523 JWT profile grants セキュリティ強化 RFC 7636 PKCE RFC 8705 Mutual-TLS bound AT RFC 9101 JAR RFC 9126 PAR RFC 9449 DPoP RFC 9470 Step Up Authentication 他 OIDC RP-Initiated Logout 1.0 RFC draft OAuth 2.1 Authorization Framework RFC 6750 OAuth 2.0 Bearer Token Usage
6. OAuth拡張仕様による 認証ユースケース対応
7. カミナシにおける認証ユースケースの一つ 現場に設置されたタブレットを複数人が共用して操作するという利用シーン。 ログインID/パスワードを共有して利用するケースも。 複数人が共有することで漏洩リスクの増大 わかりやすいパスワードの設定 退職者の不正利用リスク ログインID/パスワードの共有
8. どんな解決策がありそうか [1] https://tools.ietf.org/html/rfc8705 RFC8705 Mutual TLS Client Authentication and Certificate-Bound Access Token [1] ①クライアント証明書とともに相互TLS接続してデ バイス自身が認証しつつトークンリクエスト ②クライアント証明書に基づきクライアント認証してトークン応答 OAuth mTLSはクライアント証明書を利用した相互TLS接続に基づくクライアント認証と、証明書で 送信者制約したアクセストークンの払い出しと利用のOAuth拡張仕様。 これを利用することで、特定の端末が物理的に窃取されなければ安全なアクセスが可能となる。 端末自体のパスコードロックと組み合わせて所有+知識認証の運用も可能。
9. OAuth mTLSに対応した認可サーバーの概念構成 TLS終端装置 （ロードバランサなど） 既存の認可サーバーでクライアント証明書をインストールした タブレット端末などのクライアント認証も新たに対応したい 既存のクライアントはクライアント証明書なしでログイン処理などを継続して運用しつつ、 新たにクライアント証明書をインストールした相互TLS通信にも対応する必要がある。 既存クライアント （クライアント証明書なし） 新クライアント （クライアント証明書あり）
10. OAuth mTLSに対応した認可サーバーの概念構成 TLS終端装置 （ロードバランサなど） 既存の認可サーバーでクライアント証明書をインストールした タブレット端末などのクライアント認証も新たに対応したい 既存のクライアントはクライアント証明書なしでログイン処理などを継続して運用しつつ、 新たにクライアント証明書をインストールした相互TLS通信にも対応する必要がある。 既存クライアント （クライアント証明書なし） 新クライアント （クライアント証明書あり） nginxだったら... server { listen 443 ssl; # クライアント証明書が提示された場合だけ検証 ssl_verify_client optional; ssl_client_certificate path/to/ca.pem }
11. AWSにおける内製認証基盤 with OAuth mTLSの実現 AWSにおけるネットワークサービスと相互TLS接続機能の対応状況 ※2025/04/15時点の情報です CloudFront API Gateway ALB [2] OAuth mTLSを実現するためにAWSでできること、できないこと： https://kaminashi-developer.hatenablog.jp/entry/2024/11/18/oauth-mtls-on-aws
12. AWSにおける内製認証基盤 with OAuth mTLSの実現 AWSにおけるネットワークサービスと相互TLS接続機能の対応状況 ※2025/04/15時点の情報です CloudFront API Gateway ALB [2] OAuth mTLSを実現するためにAWSでできること、できないこと： https://kaminashi-developer.hatenablog.jp/entry/2024/11/18/oauth-mtls-on-aws
13. AWSにおける内製認証基盤 with OAuth mTLSの実現 AWSにおけるネットワークサービスと相互TLS接続機能の対応状況 ※2025/04/15時点の情報です CloudFront API Gateway ALB 信頼ストア 認可サーバー 失効検証 [2] OAuth mTLSを実現するためにAWSでできること、できないこと： https://kaminashi-developer.hatenablog.jp/entry/2024/11/18/oauth-mtls-on-aws
14. AWSにおける内製認証基盤 with OAuth mTLSの実現 AWSにおけるネットワークサービスと相互TLS接続機能の対応状況 ※2025/04/15時点の情報です CloudFront API Gateway ALB 信頼ストア 認可サーバー 失効検証 トラストストアで検証 パススルー 信頼ストア 認可サーバーで証明書検証 [2] OAuth mTLSを実現するためにAWSでできること、できないこと： https://kaminashi-developer.hatenablog.jp/entry/2024/11/18/oauth-mtls-on-aws
15. AWSにおける内製認証基盤 with OAuth mTLSの実現 AWSにおけるネットワークサービスと相互TLS接続機能の対応状況 ※2025/04/15時点の情報です CloudFront API Gateway ALB 信頼ストア 認可サーバー 失効検証 トラストストアで検証 パススルー 信頼ストア 認可サーバーで証明書検証 [2] OAuth mTLSを実現するためにAWSでできること、できないこと： https://kaminashi-developer.hatenablog.jp/entry/2024/11/18/oauth-mtls-on-aws 単一のリソースでクライアント証明書あり/なしの クライアントどちらも収容するのは難しそう...
16. AWSにおける内製認証基盤 with OAuth mTLSの実現 相互TLS接続用のALBと通常のTLS接続用ALBの2つから認証基盤のECSをターゲットに設定。 実はRFC 8705にもUX観点で相互TLS用のエンドポイントを分離した方がいいよと書いてあった。 Authorization servers supporting both clients using mutual TLS and conventional clients MAY chose to isolate the server side mutual-TLS behavior to only clients intending to do mutual TLS, thus avoiding any undesirable effects it might have on conventional clients. 信頼ストア・失効証明書リスト 通常のTLS接続用ALB 相互TLS接続用ALB
17. まとめ • 単純なパスワード認証フローのメンタルモデルから一歩進んだOpenID Connect やOAuthの拡張仕様に、専門領域の面白さが詰まっている（いわゆる沼）。 • 仕様の選択の先にはAWSサービスでの実現性検討が必要。検討結果によっては仕 様の選択に立ち戻る必要も出てくるので、AWSの仕様を理解しながら概念設計〜 実装まで一貫した検討をすることで良い体験が作れてAWS沼にもはまれる。 Zenn/manaty226 カミナシエンジニアブログ
18. 株式会社カミナシ https://kaminashi.jp