発行者サービスの通信例

Microsoft Entra 確認済み ID サービスは、お客様の組織の OpenID に準拠している ID プロバイダーによって生成された ID トークンから要求を取得することによって、検証可能な資格情報を発行できます。 この記事では、Authenticator が ID プロバイダーと通信し、発行サービスに渡す正しい ID トークンを取得できるように、ID プロバイダーを設定する方法について説明します。

検証可能な資格情報を発行するために、Authenticator は、コントラクトのダウンロードを通して、ユーザーからの入力を収集してその情報を発行サービスに送信するように指示されます。 ID トークンを使用する必要がある場合は、Authenticator が OpenID Connect プロトコルを使用してユーザーをサインインできるように ID プロバイダーを設定する必要があります。 結果として得られる ID トークン内のクレームは、検証可能な資格情報の内容を設定するために使用されます。 Authenticator は、OpenID Connect 認可コード フローを使用してユーザーを認証します。 OpenID プロバイダーでは、次の OpenID Connect 機能がサポートされている必要があります。

ID プロバイダーに送信される HTTP 要求の例は、下にあります。 ID プロバイダーは、OpenID Connect 認証標準に従って、これらの要求を受け入れて応答する必要があります。

クライアントの登録

検証可能な資格情報を受け取るには、お客様のユーザーが Microsoft Authenticator アプリからお客様の IDP にサインインする必要があります。

この交換を可能にするには、アプリケーションを ID プロバイダーに登録します。 Microsoft Entra ID を使用している場合は、こちらの手順をご覧ください。 登録時には、次の値を使用します。

アプリケーションを ID プロバイダーに登録したら、そのクライアント ID を記録します。 これは、後述のセクションで使用します。 また、OIDC と互換性のある ID プロバイダーの既知のエンドポイントへの URL も書き留めておく必要があります。 発行サービスは、このエンドポイントを使用して、Authenticator によって送信される ID トークンを検証するために必要な公開キーをダウンロードします。

構成されたリダイレクト URI は Authenticator によって使用されるので、Authenticator がサインインが完了したタイミングを認識し、ID トークンを取得できます。

Authorization request (承認要求)

ID プロバイダーに送信される認可要求には、次の形式が使用されます。

GET /authorize?client_id=<client-id>&redirect_uri=vcclient%3A%2F%2Fopenid%2F&response_mode=query&response_type=code&scope=openid&state=12345&nonce=12345 HTTP/1.1
Host: www.contoso.com
Connection: Keep-Alive

ID プロバイダーは認可要求を受信すると、ユーザーを認証し、サインインを完了するために必要なすべての手順 (多要素認証など) を実行する必要があります。

ニーズに合わせてサインイン プロセスをカスタマイズできます。 追加情報の提供、サービス使用条件への同意、資格情報の料金の支払いなどを、ユーザーに求めることができます。 すべての手順が完了したら、下に示すようなリダイレクト URI にリダイレクトすることで、認可要求に応答します。

vcclient://openid/?code=nbafhjbh1ub1yhbj1h4jr1&state=12345

トークン要求

ID プロバイダーに送信されるトークン要求の形式は次のとおりです。

POST /token HTTP/1.1
Host: www.contoso.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 291

client_id=<client-id>&redirect_uri=vcclient%3A%2F%2Fopenid%2F&grant_type=authorization_code&code=nbafhjbh1ub1yhbj1h4jr1&scope=openid

トークン要求の受信時、ID プロバイダーは ID トークンで応答する必要があります。

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
"id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ.ewogImlzc
    yI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4Mjg5
    NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAibi0wUzZ
    fV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEzMTEyODA5Nz
    AKfQ.ggW8hZ1EuVLuxNuuIJKX_V8a_OMXzR0EHR9R6jgdqrOOF4daGU96Sr_P6q
    Jp6IcmD3HP99Obi1PRs-cwh3LO-p146waJ8IhehcwL7F09JdijmBqkvPeB2T9CJ
    NqeGpe-gccMg4vfKjkM8FcGvnzZUN4_KSP0aAp1tOJ1zZwgjxqGByKHiOtX7Tpd
    QyHE5lcMiKPXfEIQILVq0pc_E2DzL7emopWoaoZTF_m0_N0YzFC6g6EJbOEoRoS
    K5hoDalrcvRYLSrQAZZKflyuVCyixEoV9GfNQC3_osjzw2PAithfubEEBLuVVk4
    XUVrWOLrLl0nx7RkKU8NXNHq-rvKMzqg"
}

ID トークンは JWT コンパクト シリアル化形式を使用する必要があり、暗号化することはできません。 ID トークンには、次のクレームが含まれている必要があります。

次の手順

• 検証可能な資格情報をカスタマイズする