はじめに
Application LoadBalancerはOIDCを使ったユーザ認証を設定することが可能です。この機能を利用すると、OIDCにおけるRelying Party（RP）の役割をALBに任せられるため、自前でRPを構築する手間が省け、非常に便利です。しかし、実際にこの機能を使ってみたところ、予期せぬセキュリティ上の課題が見つかりました。本記事では、その際に得られた知見を共有したいと思います。
本ブログに掲載している内容は、私個人の見解であり、所属する組織の立場や戦略、意見を代表するものではありません。あくまでエンジニアとしての経験や考えを発信していますので、ご了承ください。
問題点：PKCEに非対応
PKCE（Proof Key for Code Exchange by OAuth Public Clients） は、OAuth 2.0の拡張仕様であり、認可コード横取り攻撃への対策として導入されました。具体的には、下図の④の手順において認可コードが盗まれる可能性に対する対策となります。端的に言えば、認可コードの不正利用を防ぐための身元証明の仕組みです。
認可コードは認可サーバがクライアントに対し、一時的に発行するコードです。クライアントはこの認可コードを使って、アクセストークンを受け取ります。そのためこの認可コードが盗まれてしまうと、サーバ側は不正なクライアントに対し、アクセストークンを発行してしまう可能性があります。
PKCEでは下図のようにcode_verifier，code_challenge_method，code_challengeの３つのパラメータを認可のやり取りのフローで利用します。
- code_verifier:クライアントが生成するランダムな文字列
- code_challenge_method：code_verifierからcode_challengeを生成する際に使用する計算ロジックを指定
- code_challenge：上記2つから計算された結果の値
- OPはクライアントから認可リクエストと共にcode_challenge（計算結果）とcode_challenge_method（計算方法）を受け取る
- クライアントからトークンリクエストともにcode_verifier（入力値）が送られてきたとき、ＯＰは１で受け取っていたcode_challengeを使ってcode_verifierを入力値として計算を行い、その結果をcode_challengeと比較する。一致すれば正規のクライアントからのリクエストだと証明されるため、トークンを発行する。
ALBでは上図のcode_verifier，code_challenge_methodの送付ができないため、PKCEに対応していません。
まとめ
世間的にはPKCEの実装は一般的なセキュリティ対策なため、本番利用ではこちらの機能は使わないほうがよさそうです。