トークン発行イベント用にカスタムクレームプロバイダーを構成する

[アーティクル]
2025-05-04

この記事では、トークン発行開始イベント用にカスタムクレームプロバイダーを構成する方法について説明します。既存の Azure Functions REST API を使用し、カスタム認証拡張機能を登録して、REST API から解析することを期待する属性を追加します。カスタム認証拡張機能をテストするため、サンプルの OpenID Connect アプリケーションを登録してトークンを取得し、クレームを表示します。

このビデオでは、Microsoft Entra カスタムクレームプロバイダーを使用して、外部システムからの要求をセキュリティトークンにマッピングする手順について説明します。

前提条件

Azure Functions を作成できる Azure サブスクリプション。既存の Azure アカウントをお持ちでない場合は、無料試用版にサインアップするか、アカウントを作成するときに Visual Studio Subscription のベネフィットを利用できます。
Azure Functions にデプロイされたトークン発行イベント用に構成された HTTP トリガー関数。お持ちでない場合は、「Azure Functions でトークン発行開始イベント用の REST API を作成する」の手順に従ってください。
カスタム認証拡張機能の概要に関する記事で説明されている概念の基本的な理解。
Microsoft Entra ID テナント。この攻略ガイドには、顧客または従業員のどちらかのテナントを使用できます。
- 外部テナントの場合は、サインアップとサインインのユーザーフローを使用します。

手順 1: カスタム認証拡張機能を登録する

ここでは、Microsoft Entra ID が Azure 関数を呼び出すために使用するカスタム認証拡張機能を構成します。カスタム認証拡張機能には、REST API エンドポイントに関する情報、REST API から解析するクレーム、REST API に対する認証方法が含まれています。次の手順のようにして、カスタム認証拡張機能を Azure 関数アプリに登録します。

注

最大 100 個のカスタム拡張機能ポリシーを使用できます。

Azure Portal
Microsoft Graph

カスタム認証拡張機能を登録する

アプリケーション管理者および認証管理者以上の権限で Azure portal にサインインします。
[Microsoft Entra ID] を検索して選択し、[エンタープライズアプリケーション] を選択します。
[カスタム認証拡張機能] を選択して、[カスタム拡張機能の作成] を選択します。
[基本] でイベントの種類に [TokenIssuanceStart] を選択し、[次へ] を選択します。
[エンドポイントの構成] で、次のプロパティを入力します。
- [名前] - カスタム認証拡張機能の名前。例: "トークン発行イベント"。
- [ターゲット URL] - Azure 関数の URL の {Function_Url}。 Azure 関数アプリの [概要] ページに移動し、作成した関数を選択します。関数の [概要] ページで、[関数の URL の取得] を選択し、コピーアイコンを使用して customauthenticationextension_extension (システムキー) URL をコピーします。
- [説明] - カスタム認証拡張機能の説明。
[次へ] を選択します。
[API 認証] で [アプリの登録を新規作成する] オプションを選んで、"関数アプリ" を表すアプリ登録を作成します。
アプリの名前を指定します (例: Azure Functions 認証イベント API)。
[次へ] を選択します。
[要求] に、カスタム認証拡張機能で REST API から解析されてトークンにマージされる属性を入力します。次のクレームを追加します。
- 生年月日
- カスタムロール
- ApiVersion
- CorrelationId
[次へ]、[作成] の順に選択します。これにより、カスタム認証拡張機能とそれに関連付けられているアプリケーションの登録が登録されます。
[API 認証] の下の [アプリ ID] をメモします。これは、Azure 関数アプリで Azure 関数の認証を構成するために必要です。

アプリケーションの登録

ホームテナントが、カスタム認証拡張機能を管理したいテナントであるアカウントを使用して、Graph エクスプローラーにサインインします。このアカウントには、テナントでアプリケーション登録を作成および管理するための特権が必要です。

次の要求を実行します。

POST https://graph.microsoft.com/v1.0/applications
Content-type: application/json

{
    "displayName": "authenticationeventsAPI"
}

応答から、新しく作成されたアプリ登録の id と appId の値を記録します。これらの値は、この記事で {authenticationeventsAPI_ObjectId} と {authenticationeventsAPI_AppId} としてそれぞれ参照されます。

authenticationeventsAPI アプリ登録用のサービスプリンシパルをテナントに作成します。

Graph エクスプローラーで、次の要求を実行します。 {authenticationeventsAPI_AppId} を、前の手順で記録した appId の値に置き換えます。

POST https://graph.microsoft.com/v1.0/servicePrincipals
Content-type: application/json
    
{
    "appId": "{authenticationeventsAPI_AppId}"
}

アプリ ID URI、アクセストークンのバージョン、必要なリソースアクセスを設定する

新しく作成したアプリケーションを更新して、アプリケーション ID URI の値、アクセストークンのバージョン、必要なリソースアクセスを設定します。

Graph エクスプローラーで、次の要求を実行します。

identifierUris プロパティにアプリケーション ID URI の値を設定します。 {Function_Url_Hostname} を、前に記録した {Function_Url} のホスト名に置き換えます。
前に記録した {authenticationeventsAPI_AppId} で値を設定します。
値の例は api://authenticationeventsAPI.azurewebsites.net/00001111-aaaa-2222-bbbb-3333cccc4444 です。この値は、{functionApp_IdentifierUri} の代わりにこの記事の後半で使用するので、メモしておきます。

POST https://graph.microsoft.com/v1.0/applications/{authenticationeventsAPI_ObjectId}
Content-type: application/json

{
"identifierUris": [
    "api://{Function_Url_Hostname}/{authenticationeventsAPI_AppId}"
],    
"api": {
    "requestedAccessTokenVersion": 2,
    "acceptMappedClaims": null,
    "knownClientApplications": [],
    "oauth2PermissionScopes": [],
    "preAuthorizedApplications": []
},
"requiredResourceAccess": [
    {
        "resourceAppId": "00000003-0000-0000-c000-000000000000",
        "resourceAccess": [
            {
                "id": "00aa00aa-bb11-cc22-dd33-44ee44ee44ee",
                "type": "Role"
            }
        ]
    }
]
}

カスタム認証拡張機能を登録する

カスタム認証拡張機能を登録するには、それを Azure 関数のアプリ登録および Azure 関数エンドポイント {Function_Url} と関連付けます。

Graph エクスプローラーで、次の要求を実行します。 {Function_Url} を Azure 関数アプリのホスト名に置き換えます。 {functionApp_IdentifierUri} は、前のステップで使った identifierUri に置き換えます。

CustomAuthenticationExtension.ReadWrite.All の委任されたアクセス許可が必要です。

POST https://graph.microsoft.com/beta/identity/customAuthenticationExtensions
Content-type: application/json

{
    "@odata.type": "#microsoft.graph.onTokenIssuanceStartCustomExtension",
    "displayName": "onTokenIssuanceStartCustomExtension",
    "description": "Fetch additional claims from custom user store",
    "endpointConfiguration": {
        "@odata.type": "#microsoft.graph.httpRequestEndpoint",
        "targetUrl": "{Function_Url}"
    },
    "authenticationConfiguration": {
        "@odata.type": "#microsoft.graph.azureAdTokenAuthentication",
        "resourceId": "{functionApp_IdentifierUri}"
    },
    "claimsForTokenConfiguration": [
        {
            "claimIdInApiResponse": "DateOfBirth"
        },
        {
            "claimIdInApiResponse": "CustomRoles"
        }
    ]
}

作成されたカスタムクレームプロバイダーオブジェクトの id の値を記録しておきます。この値は、このチュートリアルの後半で {customExtensionObjectId} の代わりに使います。

カスタム認証拡張機能が作成されたら、API にアクセス許可を付与する必要があります。カスタム認証拡張機能は、client_credentials を使い、Receive custom authentication extension HTTP requests アクセス許可を使って Azure Function App に対する認証を行います。

新しいカスタム認証拡張機能の概要ページを開きます。 ID プロバイダーを追加するときに必要になるため、[API 認証] の下にあるアプリ ID を書き留めます。
[API 認証] の下にある [アクセス許可の付与] を選択します。
新しいウィンドウが開き、サインインすると、カスタム認証拡張機能の HTTP 要求を受信するためのアクセス許可が要求されます。これで、API に対してカスタム認証拡張機能を認証できるようになります。 [Accept](承認) を選択します。

手順 2: エンリッチされたトークンを受信するように OpenID Connect アプリを構成する

トークンを取得してカスタム認証拡張機能をテストするには、https://jwt.ms アプリを使用できます。これは Microsoft 所有の Web アプリケーションであり、トークンのデコードされた内容を表示します (トークンの内容がお使いのブラウザーの外に出ることはありません)。

2.1 テスト Web アプリケーションを登録する

次の手順のようにして、jwt.ms Web アプリケーションを登録します。

Azure portal のホームページで、[Microsoft Entra ID]を選択します。
[アプリの登録]>[新しい登録] の順に選びます。
アプリケーションの名前を入力します。例: マイテストアプリケーション。
[サポートされているアカウントの種類] で、 [この組織のディレクトリ内のアカウントのみ] を選択します。
[リダイレクト URI] の [プラットフォームの選択] ドロップダウンで [Web] を選び、[URL] テキストボックスに「https://jwt.ms」と入力します。
[登録] を選んで、アプリの登録を完了します。
アプリの登録の概要ページで、[アプリケーション (クライアント) ID] をコピーします。後の手順では、アプリ ID を {App_to_enrich_ID} として参照します。 Microsoft Graph では、appId プロパティによって参照されます。

2.2 暗黙的なフローを有効にする

jwt.ms テストアプリケーションでは、暗黙的なフローを使います。 "マイテストアプリケーション" の登録で暗黙的なフローを有効にします。

重要

Microsoft では、使用可能な最も安全な認証フローを使用することをお勧めします。この手順でテストに使用される認証フローは、アプリケーションで非常に高いレベルの信頼を必要とするため、他のフローには存在しないリスクが伴います。この方法は、運用アプリに対するユーザーの認証には使用しないでください (詳細情報)。

[管理] で、 [認証] を選択します。
[暗黙的な許可およびハイブリッドフロー] で、[ID トークン (暗黙的およびハイブリッドフローに使用)] チェックボックスをオンにします。
[保存] を選択します。

2.3 クレームマッピングポリシーに対してアプリを有効にする

カスタム認証拡張機能から返された属性から、トークンにマップされるものを選ぶには、クレームマッピングポリシーを使います。トークンを拡張できるようにするには、アプリケーション登録によるマップされたクレームの受け入れを明示的に有効にする必要があります。

"マイテストアプリケーション" の登録で、[管理] の [マニフェスト] を選びます。
マニフェストで acceptMappedClaims 属性を見つけて、値を true に設定します。
requestedAccessTokenVersion を 2 に設定します。
[保存] を選択して変更を保存します。

次の JSON スニペットでは、これらのプロパティを構成する方法を示します。

{
	"id": "22222222-0000-0000-0000-000000000000",
	"acceptMappedClaims": true,
	"requestedAccessTokenVersion": 2,  
    ...
}

警告

acceptMappedClaims プロパティをマルチテナントアプリの true に設定しないでください。これにより、悪意のあるアクターがアプリのクレームマッピングポリシーを作成できる可能性があります。代わりに、カスタム署名キーを構成します。

従業員テナント
外部テナント

次のステップ「カスタムクレームプロバイダーをアプリに割り当てる」に進みます。

手順 3: カスタムクレームプロバイダーをアプリに割り当てる

カスタム認証拡張機能から受け取ったクレームでトークンが発行されるようにするには、カスタムクレームプロバイダーをアプリケーションに割り当てる必要があります。これはトークンの対象ユーザーに基づいているため、ID トークンで要求を受け取るにはクライアントアプリケーションにプロバイダーを割り当て、アクセストークンで要求を受け取るにはリソースアプリケーションにプロバイダーを割り当てる必要があります。カスタムクレームプロバイダーは、トークン発行開始イベントリスナーで構成されたカスタム認証拡張機能に依存します。カスタムクレームプロバイダーからのクレームのすべてまたはサブセットのどちらを、トークンにマップするかを選択できます。

注

アプリケーションとカスタム拡張機能の間で作成できる一意の割り当ては 250 個のみです。複数のアプリに同じカスタム拡張機能呼び出しを適用する場合は、 authenticationEventListeners Microsoft Graph API を使用して、複数のアプリケーションのリスナーを作成することをお勧めします。これは Azure portal ではサポートされていません。

次の手順のようにして、マイテストアプリケーション とカスタム認証拡張機能を接続します。

Azure Portal
Microsoft Graph

カスタム認証拡張機能をカスタムクレームプロバイダーソースとして割り当てるには、次を行います。

Azure portal のホームページで、[Microsoft Entra ID]を選択します。
[エンタープライズアプリケーション] を選択し、その後 [管理] で、[すべてのアプリケーション] を選択します。一覧から[マイテストアプリケーション] を選択します。
"マイテストアプリケーション" の概要ページで、[管理] に移動し、[シングルサインオン] を選択します。
[属性とクレーム] で、[編集] を選びます。
[詳細設定] メニューを展開します。
[カスタムクレームプロバイダー] の横にある [構成] を選択します。
[Custom claims provider] (カスタムクレームプロバイダー) ドロップダウンボックスを展開して、前に作成した "トークン発行イベント" を選びます。
[保存] を選択します。

次に、カスタムクレームプロバイダーから属性を割り当てます。これは、クレームとしてトークンに発行されている必要があります。

[新しクレームの追加] を選んで、新しいクレームを追加します。発行する要求に名前を指定します (例: DateOfBirth)。
[ソース] で [属性] を選択し、[ソース属性] ドロップダウンボックスから customClaimsProvider.DateOfBirth を選択します。
[保存] を選択します。
このプロセスを繰り返して、[customClaimsProvider.customRoles]、[customClaimsProvider.apiVersion]、[customClaimsProvider.correlationId] の属性と、それぞれに対応する名前を追加します。クレームの名前と属性の名前は一致させることをお勧めします。

最初に、トークン発行開始イベントを使って My Test アプリケーション のカスタム認証拡張機能をトリガーするイベントリスナーを作成します。

ホームテナントがカスタム認証拡張機能を管理するテナントであるアカウントを使い、Graph エクスプローラーにサインインします。

次の要求を実行します。 {App_to_enrich_ID} を、前に記録した "マイテストアプリケーション" のアプリ ID に置き換えます。 {customExtensionObjectId} を、前に記録したカスタム認証拡張機能の ID に置き換えます。

EventListener.ReadWrite.All の委任されたアクセス許可が必要です。

POST https://graph.microsoft.com/beta/identity/authenticationEventListeners
Content-type: application/json

{
    "@odata.type": "#microsoft.graph.onTokenIssuanceStartListener",
    "conditions": {
        "applications": {
            "includeAllApplications": false,
            "includeApplications": [
                {
                    "appId": "{App_to_enrich_ID}"
                }
            ]
        }
    },
    "priority": 500,
    "handler": {
        "@odata.type": "#microsoft.graph.onTokenIssuanceStartCustomExtensionHandler",
        "customExtension": {
            "id": "{customExtensionObjectId}"
        }
    }
}

次に、カスタムクレームプロバイダーからアプリケーションに発行できるクレームが記述されているクレームマッピングポリシーを作成します。

引き続き Graph エクスプローラーで、次の要求を実行します。 Policy.ReadWrite.ApplicationConfiguration の委任されたアクセス許可が必要です。

POST https://graph.microsoft.com/v1.0/policies/claimsMappingPolicies
Content-type: application/json

{
    "definition": [
        "{\"ClaimsMappingPolicy\":{\"Version\":1,\"IncludeBasicClaimSet\":\"true\",\"ClaimsSchema\":[{\"Source\":\"CustomClaimsProvider\",\"ID\":\"DateOfBirth\",\"JwtClaimType\":\"dob\"},{\"Source\":\"CustomClaimsProvider\",\"ID\":\"CustomRoles\",\"JwtClaimType\":\"my_roles\"},{\"Source\":\"CustomClaimsProvider\",\"ID\":\"CorrelationId\",\"JwtClaimType\":\"correlationId\"},{\"Source\":\"CustomClaimsProvider\",\"ID\":\"ApiVersion\",\"JwtClaimType\":\"apiVersion \"},{\"Value\":\"tokenaug_V2\",\"JwtClaimType\":\"policy_version\"}]}}"
    ],
    "displayName": "MyClaimsMappingPolicy",
    "isOrganizationDefault": false
}

応答で生成された ID を記録します。後で {claims_mapping_policy_ID} として参照します。

サービスプリンシパルオブジェクト ID を取得します。

Graph エクスプローラーで、次の要求を実行します。 {App_to_enrich_ID} を My Test Application の appId に置き換えます。
```
GET https://graph.microsoft.com/v1.0/servicePrincipals(appId='{App_to_enrich_ID}')
```

ID の値を記録します。

クレームマッピングポリシーを My Test Application のサービスプリンシパルに割り当てます。

Graph エクスプローラーで、次の要求を実行します。 Policy.ReadWrite.ApplicationConfiguration と Application.ReadWrite.All の委任されたアクセス許可が必要です。

POST https://graph.microsoft.com/v1.0/servicePrincipals/{test_App_Service_Principal_ObjectId}/claimsMappingPolicies/$ref
Content-type: application/json

{
    "@odata.id": "https://graph.microsoft.com/v1.0/policies/claimsMappingPolicies/{claims_mapping_policy_ID}"
}

手順 4: Azure 関数を保護する

Microsoft Entra カスタム認証拡張機能は、サーバー間フローを使って、HTTP の Authorization ヘッダーで Azure 関数に送信されるアクセストークンを取得します。関数を Azure に発行するときは、特に運用環境では、Authorization ヘッダーで送信されるトークンを検証する必要があります。

Azure 関数を保護するには、Microsoft Entra 認証を統合し、受信したトークンを Azure Functions 認証イベント API アプリケーション登録で検証するため、次の手順に従います。テナントの種類に基づいて、次のいずれかのタブを選択します。

注

Azure 関数アプリが、カスタム認証拡張機能が登録されているテナントとは異なる Azure テナントでホストされている場合は、[OpenID Connect] タブを選択してください。

4.1 Microsoft Entra ID の ID プロバイダーの使用

ID プロバイダーとして Microsoft Entra を Azure 関数アプリに追加するには、次のステップに従います。

従業員テナント
外部テナント

Azure portal で、前に発行した関数アプリを探して選択します。
[設定] で [認証] を選択します。
[ID プロバイダーの追加] を選びます。
ID プロバイダーとして [Microsoft] を選択します。
テナントの種類として [従業員] を選択します。
[アプリの登録] の下で、[アプリ登録の種類] に [このディレクトリ内の既存のアプリ登録を選択] を選択し、カスタムクレームプロバイダーの登録時に前に作成した "Azure Functions 認証イベント API" アプリ登録を選択します。
発行者 URL https://login.microsoftonline.com/{tenantId}/v2.0 を入力します。ここで、{tenantId} は従業員テナントのテナント ID です。
[クライアントアプリケーション要件] で、[特定のクライアントアプリケーションからの要求を許可する] を選択し、99045fe1-7639-4a75-9d4a-577b6ca3810f を入力します。
[テナント要件] で、[特定のテナントからの要求を許可する] を選択し、従業員テナント ID を入力します。
[認証されていない要求] で、ID プロバイダーとして [HTTP 401 認可されていない] を選択します。
[トークンストア] オプションをオフにします。
[追加] を選んで、Azure 関数に認証を追加します。

Azure portal で、前に発行した関数アプリを探して選択します。
[設定] で [認証] を選択します。
[ID プロバイダーの追加] を選びます。
ID プロバイダーとして [Microsoft] を選択します。
テナントの種類として [外部構成] を選択します。
[アプリの登録] の下で、[アプリ登録の種類] に [既存のアプリ登録の詳細を入力する] を選択し、カスタムクレームプロバイダーの登録時にclient_id"Azure Functions 認証イベント API" アプリ登録のを入力します。
[発行者 URL] に、URL https://{domainName}.ciamlogin.com/{tenant_id}/v2.0 を入力します。ここで
- {domainName} は、{domainName}.contoso.com の形式の、外部テナントのドメイン名です。
- {tenantId} は外部テナントのテナント ID です。
[クライアントアプリケーション要件] で、[特定のクライアントアプリケーションからの要求を許可する] を選択し、99045fe1-7639-4a75-9d4a-577b6ca3810f を入力します。
[テナント要件] で、[特定のテナントからの要求を許可する] を選択し、外部テナント ID を入力します。
[認証されていない要求] で、ID プロバイダーとして [HTTP 401 認可されていない] を選択します。
[トークンストア] オプションをオフにします。
[追加] を選んで、Azure 関数に認証を追加します。

4.2 OpenID Connect ID プロバイダーの使用

Microsoft ID プロバイダーを構成した場合は、このステップをスキップします。そうではなく、カスタム認証拡張機能が登録されているテナントとは異なるテナントで Azure 関数がホストされている場合は、次の手順のようにして関数を保護します。

クライアントシークレットの作成

Azure portal のホーム ページから、[Microsoft Entra ID]>[アプリの登録] を選択します。
前に作成した "Azure Functions 認証イベント API" アプリの登録を選択します。
[証明書とシークレット]>[Client secrets]\(クライアントシークレット\)>[新しいクライアントシークレット] の順に選択します。
シークレットの有効期限を選択するか、カスタムの有効期間を指定し、説明を追加して、[追加] を選択します。
クライアントアプリケーションのコードで使用できるように、シークレットの値を記録しておきます。このページからの移動後は、このシークレットの値は "二度と表示されません"。

OpenID Connect ID プロバイダーを Azure 関数アプリに追加します。

前に発行した関数アプリを探して選択します。
[設定] で [認証] を選択します。
[ID プロバイダーの追加] を選びます。
ID プロバイダーとして [OpenID Connect] を選びます。
Contoso Microsoft Entra ID などの名前を指定します。
[メタデータエントリ] で、[ドキュメントの URL] に次の URL を入力します。 {tenantId} を Microsoft Entra テナント ID に置き換えます。
```
https://login.microsoftonline.com/{tenantId}/v2.0/.well-known/openid-configuration
```
[アプリの登録] で、前に作成した "Azure Functions 認証イベント API" アプリ登録のアプリケーション ID (クライアント ID) を入力します。
Azure 関数に戻り、[アプリの登録] の下で [クライアントシークレット] を入力します。
[トークンストア] オプションをオフにします。
[追加] を選んで、OpenID Connect ID プロバイダーを追加します。

ステップ 5: アプリケーションをテストする

カスタムクレームプロバイダーをテストするには、次のステップに従います。

従業員テナント
外部テナント

新しいプライベートブラウザーを開き、次の URL に移動してサインインします。

https://login.microsoftonline.com/{tenantId}/oauth2/v2.0/authorize?client_id={App_to_enrich_ID}&response_type=id_token&redirect_uri=https://jwt.ms&scope=openid&state=12345&nonce=12345

{tenantId} は、テナント ID、テナント名、または検証済みドメイン名の 1 つに置き換えます。たとえば、contoso.onmicrosoft.com のようにします。
{App_to_enrich_ID} を、"マイテストアプリケーション" クライアント ID に置き換えます。
ログインすると、https://jwt.ms でデコードされたトークンが表示されます。 Azure 関数からのクレームがデコードされたトークンで提示されていることを確認します (例: DateOfBirth)。

新しいプライベートブラウザーを開き、次の URL に移動してサインインします。

https://{domainName}.ciamlogin.com/{tenantId}/oauth2/v2.0/authorize?client_id={App_to_enrich_ID}&response_type=id_token&redirect_uri=https://jwt.ms&scope=openid&state=12345&nonce=12345

{domainName} を自分のドメイン名 (contoso など) に置き換えます。
{tenantId} は、テナント ID、テナント名、または検証済みドメイン名の 1 つに置き換えます。たとえば、contoso.onmicrosoft.com のようにします。
{App_to_enrich_ID} を、"マイテストアプリケーション" クライアント ID に置き換えます。
構成したサインインユーザーフローを確認し、要求されたアクセス許可を受け入れます。
ログインすると、https://jwt.ms でデコードされたトークンが表示されます。 Azure 関数からのクレームがデコードされたトークンで提示されていることを確認します (例: DateOfBirth)。

次の方法で共有

カスタム認証拡張機能を登録する

アプリケーションの登録

authenticationeventsAPI アプリ登録用のサービスプリンシパルをテナントに作成します。

アプリ ID URI、アクセストークンのバージョン、必要なリソースアクセスを設定する

カスタム認証拡張機能を登録する

3.4 アプリをユーザーフローに関連付ける

次の方法で共有

トークン発行イベント用にカスタム クレーム プロバイダーを構成する

前提条件

手順 1: カスタム認証拡張機能を登録する

カスタム認証拡張機能を登録する

1.2 管理者の同意の付与

手順 2: エンリッチされたトークンを受信するように OpenID Connect アプリを構成する

2.1 テスト Web アプリケーションを登録する

2.2 暗黙的なフローを有効にする

2.3 クレーム マッピング ポリシーに対してアプリを有効にする

手順 3: カスタム クレーム プロバイダーをアプリに割り当てる

手順 4: Azure 関数を保護する

4.1 Microsoft Entra ID の ID プロバイダーの使用

4.2 OpenID Connect ID プロバイダーの使用

クライアント シークレットの作成

OpenID Connect ID プロバイダーを Azure 関数アプリに追加します。

ステップ 5: アプリケーションをテストする

関連項目

フィードバック

その他のリソース

トークン発行イベント用にカスタムクレームプロバイダーを構成する

2.3 クレームマッピングポリシーに対してアプリを有効にする

手順 3: カスタムクレームプロバイダーをアプリに割り当てる

クライアントシークレットの作成