AWSのApplication Load Balancerには、OIDCを設定して簡単に認証を組み込むことができます。
詳細は公式ドキュメントを参照ください。
https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/listener-authenticate-users.html
そのときにAzure ADをOIDCのIDプロバイダーとして使ったのですが、Azure ADはID Tokenやアクセストークンに様々な情報を付与することができます。
詳細は公式ドキュメントを参照ください。
https://docs.microsoft.com/ja-jp/azure/active-directory/develop/active-directory-optional-claims
どうハマったのか
公式ドキュメントの引用ですが、ALBは認証した時の情報をヘッダーに付加してくれます。
ロードバランサーは以下の HTTP ヘッダーを追加します。
x-amzn-oidc-accesstoken
トークンエンドポイントからのアクセストークン (プレーンテキスト)。
x-amzn-oidc-identity
ユーザー情報エンドポイントからの件名フィールド (sub) (プレーンテキスト)。
x-amzn-oidc-data
ユーザークレーム (JSON ウェブトークン (JWT) 形式)
ユーザークレームはx-amzn-oidc-dataから取ることができるようなので、こちらから必要な情報を取るように実装しました。
ただ、x-amzn-oidc-dataのJWTをデコードしても、上記にAzureのドキュメントに書いてある様々な情報が全く設定されておらずかなりハマりました。
どう解決したのか
Azureのドキュメントをよく読むと、『ID Tokenやアクセストークンに様々な情報を付与する』と書いてあります。
アクセストークンはx-amzn-oidc-accesstokenに入っています。
こちらは使わないと思い、当初は確認していなかったのですが値を見てみたらJWTが入っていました。
x-amzn-oidc-accesstokenから取得できたJWTをデコードしたらきちんとAzureが設定した様々な情報を取得することができました！！
JWTの検証でもハマった
JWTが正しく生成されたものかは署名を検証することで確認することができます。
ここでも少しハマりました。
x-amzn-oidc-dataのJWTはAWSが生成したものなのでAWSが提供している公開鍵で検証することができます。
手順は最初に記載したAWSのドキュメントに記載されています。
一方、x-amzn-oidc-accesstokenに設定されているJWTはAzureが生成したものなのでAzureが提供している公開鍵を使って検証する必要があります。
Azureの方は公式ドキュメントを探しても検証の仕方が全然見つからなかったのですが、下記のページがかなり役に立ちました。
https://tsmatz.wordpress.com/2015/02/17/azure-ad-service-access-token-validation-check/