API Management で Azure AD B2C を利用した認証の構成手順について
こんにちは、PaaS Developer チームの陳です。
API Management（以下 APIM）の資格情報マネージャーを構成して、バックエンドを認証する方法について、Entra ID をプロバイダとして構成する方法を以下のドキュメントに掲載されていますが、
資格情報マネージャーの構成 - Microsoft Graph API
Azure AD B2C を使用して構成する方法はないため、今回は APIM で Azure AD B2C を用いた バックエンド認証の構成手順についてまとめます。
質問
APIM での バックエンド認証には、Entra ID ではなく、Azure AD B2C を使用する予定ですが、Credential Manager とポリシーの構成方法について知りたい。
回答
本ブログは以下の流れで説明していきます。
Azure AD B2C の構成手順
1. Azure AD B2C テナントを作成し、左側メニューの「アプリの登録」でアプリを作成します
アプリの作成
リダイレクト URL は一旦空のままで大丈夫ですが、のちほど APIM での設定において認証のためのリダイレクト URL が指定されるため、その際に入力します。
2. 作成したアプリで各種設定をします
「 証明書とシークレット 」でシークレットを作成し、値をメモします。（作成後には再び参照できないため、作成時に値のメモを忘れなく）
「 API の公開 」でアプリケーション ID URL を作成し、スコープの追加でスコープを追加します。
3. ユーザーフローの定義
ここでは具体的にどのような認証方法を採用するかを設定できます。複数のユーザーフローを定義できるため、下記 4 の Authorization URL に適用したいユーザーフローポリシー名を含めることで、どのポリシーを適用するかを設定できます。後ほど述べる APIM での Credential Manager の構成において、最後に構成した接続を認証する際にユーザーフローの動作を確認できます。 ここでは、例として MFA を使用してメールか電話番号の追加認証を導入するユーザーフローを定義してみます。
ほかにもトークン内に含める情報（ issuer 、sub など）やトークンの有効期間などを編集できるため、実際の運用要件に応じて設定していただければと思います。
4. Azure AD B2C で認証するためのユーザーを作成します
後述する Credential Manager の接続認証において、ユーザーとして一回ログインする必要があるため、ここで予めユーザーを作成しておきます。
添付のスクリーンショットのように、Azure AD B2C の 「 ユーザー 」から新しいユーザーをクリックし、ユーザープリンシパルとパスワードを設定します。パスワードは作成後に再び参照できないため、事前にメモしてください。
5. APIM の Credential Manager を構成するための情報を整理します
| 名前 | 説明 |
|---|---|
| Authorization URL | https:// |
| Client ID | アプリの概要から確認できます |
| Client Secret | 作成したシークレット値 |
| Token URL | https:// |
| Scopes | 作成したスコープのURL |
- userflow-policy-name は 手順3 で作成したユーザーフローの名前を入力。
- Client ID は 手順1 で作成したアプリの概要で確認できます。
- Client Screct は 手順2 でメモしたシークレット値を入力。
- Scopes は 手順2 で作成したスコープをそのままコピペする。
APIM Credential Manager の構成手順
APIM の Credential Manager で作成を押したら以下の画面となり、さきほど整理した情報を各項目に入力します。
今回は Entra ID ではなく、Azure AD B2C での認証のため、ID プロバイダを OAuth2.0 にします。
作成したら、APIM のリダイレクト URL を教えてくれますので、その URL をアプリのリダイレクト URL に設定します。
設定が終わりましたら、作成した Credential Manager の Connections メニューで Connections を作成します。 作成後の画面の OAuth2.0でのログイン、もしくは下の画面でログインボタンをクリックし、定義した認証方法で状態が Connected になったかをご確認ください。
今回は例として MFA の追加認証を設定したため、さきほど作成したユーザーでログインし、追加認証があるかどうかを確認します。
ログイン出来たら、下記の図で確認できるように電話番号は求められているため、ユーザーフローポリシーは正しく動作していると分かります。
電話番号で認証できたら、Credential Manager の接続状態が Connected となり、認証が成功となります。
以上で Credential Manager の構成は完了ですので、最後は APIM ポリシーの構成となります。
ポリシーの構成手順
今回使用するポリシーは「 get-authorization-context 」となります。 認証の流れとしては、まずポリシー内で指定した Credential Manager に構成した authentication URL を通じてクライアント認証情報で承認コードをもらいます。
それから、承認コードを使用して Token URL でアクセストークンをもらいます。それ以降は要件に応じてトークンをヘッダーに添付して認証するなどのプロセスを各自で構築できます。
ポリシーの構文例を以下に示します。
<inbound>
<base />
<get-authorization-context provider-id="b2ctest" authorization-id="b2ctest" context-variable-name="auth-context" identity-type="managed" ignore-error="false" />
<!-- Return the token -->
<return-response>
<set-status code="200" />
<set-body template="none">@(((Authorization)context.Variables.GetValueOrDefault("auth-context"))?.AccessToken)</set-body>
</return-response>
</inbound>
ここで、注意点として identity-type を jwt ではなく、managed にすることです。
理由としては、Azure AD B2C を使用して取得したトークンには tenant id が含まれていないため、jwt トークンとして認証してしまうと tenant id error となります。
参考ドキュメント
2024 年 08 月 16 日時点の内容となります。
本記事の内容は予告なく変更される場合がございますので予めご了承ください。