ID トークンの検証可能な資格情報を作成する
idTokens 構成証明を使用するルール定義では、Microsoft Authenticator で OpenID Connect (OIDC) ID プロバイダーへの対話型サインインを行う必要がある発行フローが生成されます。 ID プロバイダーが返す ID トークン内の要求を使用して、発行された検証可能な資格情報を設定できます。 ルール定義の要求マッピング セクションでは、使用する要求を指定します。
idToken の構成証明の種類を使用してカスタム資格情報を作成する
Azure portal で [資格情報の追加] を選ぶと、2 つのクイックスタートを起動するオプションが表示されます。 [カスタム資格情報] を選び、[次へ] を選びます。
[新しい資格情報の作成] ページで、表示とルールの定義用の JSON コードを入力します。 [資格情報名] ボックスで、資格情報に種類の名前を付けます。 [作成] を選び、資格情報を作成します。
JSON 表示定義のサンプル
構成証明の種類に関係なく、JSON 表示の定義はほとんど同じです。 検証可能な資格情報が持つ要求に従ってラベルを調整する必要があるだけです。 表示定義に想定される JSON は、表示コレクションの内部コンテンツです。 JSON はコレクションであるため、複数のロケールをサポートする場合は、コンマを区切りとして使用して複数のエントリを追加します。
{
"locale": "en-US",
"card": {
"title": "Verified Credential Expert",
"issuedBy": "Microsoft",
"backgroundColor": "#000000",
"textColor": "#ffffff",
"logo": {
"uri": "https://didcustomerplayground.z13.web.core.windows.net/VerifiedCredentialExpert_icon.png",
"description": "Verified Credential Expert Logo"
},
"description": "Use your verified credential to prove to anyone that you know all about verifiable credentials."
},
"consent": {
"title": "Do you want to get your Verified Credential?",
"instructions": "Sign in with your account to get your card."
},
"claims": [
{
"claim": "vc.credentialSubject.userName",
"label": "User name",
"type": "String"
},
{
"claim": "vc.credentialSubject.displayName",
"label": "Display name",
"type": "String"
},
{
"claim": "vc.credentialSubject.firstName",
"label": "First name",
"type": "String"
},
{
"claim": "vc.credentialSubject.lastName",
"label": "Last name",
"type": "String"
}
]
}
JSON ルール定義のサンプル
JSON 構成証明の定義には、idToken 名、OIDC 構成の詳細 (clientId、configuration、redirectUri、scope)、要求マッピング セクションが含まれている必要があります。 ルール定義に想定される JSON は、構成証明属性で始まるルール属性の内部コンテンツです。
次の例の要求マッピングでは、「ID プロバイダーからの ID トークンの要求」セクションで説明されているように、トークンを構成する必要があります。
{
"attestations": {
"idTokens": [
{
"clientId": "00001111-aaaa-2222-bbbb-3333cccc4444",
"configuration": "https://didplayground.b2clogin.com/didplayground.onmicrosoft.com/B2C_1_sisu/v2.0/.well-known/openid-configuration",
"redirectUri": "vcclient://openid/",
"scope": "openid profile email",
"mapping": [
{
"outputClaim": "userName",
"required": true,
"inputClaim": "$.upn",
"indexed": true
},
{
"outputClaim": "displayName",
"required": true,
"inputClaim": "$.name",
"indexed": false
},
{
"outputClaim": "firstName",
"required": true,
"inputClaim": "$.given_name",
"indexed": false
},
{
"outputClaim": "lastName",
"required": true,
"inputClaim": "$.family_name",
"indexed": false
}
],
"required": false
}
]
},
"validityInterval": 2592000,
"vc": {
"type": [
"VerifiedCredentialExpert"
]
}
}
アプリケーションの登録
clientId 属性は、OIDC ID プロバイダーに登録されているアプリケーションのアプリケーション ID です。 Microsoft Entra ID の場合は、次の操作を行ってアプリケーションを作成します。
Azure portal で、[Microsoft Entra ID] に移動します。
[アプリの登録] を選択して、[新規登録] を選択し、アプリに名前を付けます
テナント内のアカウントのみをサインインできるようにする場合は、[このディレクトリのアカウントのみ] チェック ボックスをオンのままにします。
[リダイレクト URI (省略可能)] で、[パブリック クライアント/ネイティブ (モバイル デスクトップ)] を選択し、「vcclient://openid/」と入力します。
Microsoft Entra トークン内にどのクレームがあるかをテストできるようにするには、次の手順に従います。
左側のウィンドウで、[認証]>[プラットフォームの追加]>[Web] を選択します。
[リダイレクト URI] に「https://jwt.ms」と入力し、[ID トークン (暗黙的およびハイブリッド フローに使用)] を選択します。
[構成] をクリックします。
ID トークンのテストが完了したら、https://jwt.ms の削除と暗黙的フローとハイブリッド フローのサポートを検討する必要があります。
Microsoft Entra ID の場合: アプリの登録をテストできます。また、https://jwt.ms へのリダイレクトのサポートを有効にしている場合は、ブラウザーで次を実行して ID トークンを取得できます。
https://login.microsoftonline.com/<your-tenantId>/oauth2/v2.0/authorize?client_id=<your-appId>&nonce=defaultNonce&redirect_uri=https%3A%2F%2Fjwt.ms&scope=openid%20profile&response_type=id_token&prompt=login
コードの <your-tenantId> をテナント ID に置き換えます。 追加の要求を取得するには、スコープの一部としてプロファイルが必要です。
Azure Active Directory B2C の場合: アプリ登録プロセスは同じですが、B2C では、ユーザー フローの実行機能を使用して B2C ポリシーをテストするためのサポートが Azure portal に組み込まれています。
ID プロバイダーからの ID トークンの要求
要求が検証可能な資格情報に正常に入力されるように、それらが返された ID プロバイダーに存在する必要があります。
要求が存在しない場合は、発行された検証可能な資格情報に値はありません。 要求のプロファイルに null 値があると、ほとんどの OIDC ID プロバイダーは、ID トークンで要求を発行しません。 ID トークン定義に要求を含め、ユーザー プロファイルの要求に値が入力されるようにしてください。
Microsoft Entra ID の場合: トークンに含めるクレームを構成するには、「アプリに省略可能な要求を提供する」を参照してください。 構成はアプリケーションごとに行われるので、この構成は、ルール定義のクライアント ID で指定されたアプリケーション ID を持つアプリに対するものである必要があります。
表示とルールの定義に一致させるには、アプリケーションの optionalClaims JSON を次のようにする必要があります。
"optionalClaims": {
"idToken": [
{
"name": "upn",
"source": null,
"essential": false,
"additionalProperties": []
},
{
"name": "family_name",
"source": null,
"essential": false,
"additionalProperties": []
},
{
"name": "given_name",
"source": null,
"essential": false,
"additionalProperties": []
},
{
"name": "preferred_username",
"source": null,
"essential": false,
"additionalProperties": []
}
],
"accessToken": [],
"saml2Token": []
},
Azure Active Directory B2C の場合: ID トークン内の他の要求の構成は、B2C ポリシーがユーザー フローまたはカスタム ポリシーであるかどうかによって異なります。 ユーザー フローの詳細については、「Azure Active Directory B2C でのサインアップとサインイン フローの設定」を参照してください。 カスタム ポリシーの詳細については、「アプリにオプションの要求を提供する」を参照してください。
他の ID プロバイダーについては、関連するドキュメントを参照してください。
カスタム資格情報を発行して確認するようにサンプルを構成する
カスタム資格情報を発行および確認するサンプル コードを構成するには、次のものが必要です。
- テナントの発行者分散化識別子 (DID)
- 新しい資格情報の種類
- 資格情報のマニフェスト URL
カスタム資格情報のこの情報を見つける最も簡単な方法は、Azure portal で資格情報に移動することです。 [Issue credential] (資格情報の発行) を選びます。 その後、Request Service API の JSON ペイロードを含むテキスト ボックスにアクセスできます。 プレースホルダーの値を環境の情報に置き換えます。 発行者の DID は機関の値です。
次のステップ
「ルールと表示の定義リファレンス」を参照してください。