App Service 認証の API とランタイムのバージョンを管理する

この記事では、 App Service の組み込み認証と承認の API バージョンとランタイム バージョンをカスタマイズする方法について説明します。

App Service 認証用の管理 API には、2 つのバージョンがあります。 Azure portal での認証エクスペリエンスには、V2 バージョンが必要です。 V1 API を既に使用しているアプリは、いくつかの変更が行われた後、V2 バージョンにアップグレードできます。 具体的には、シークレット構成を、スロット固定のアプリケーション設定に移動する必要があります。 シークレット構成は、ポータルのアプリの [認証 ] セクションから自動的に移動できます。

構成バージョンを更新する

警告

V2 への移行により、Azure portal、Azure CLI、Azure PowerShell での既存のエクスペリエンスなど、一部のクライアントを介したアプリケーションの App Service 認証/承認機能の管理が無効になります。 この移行を元に戻すことはできません。

V2 API では、V1 と同様に、Microsoft アカウントの作成や編集は個別のプロバイダーとしてサポートされていません。 代わりに、統合 された Microsoft ID プラットフォーム を使用して、Microsoft Entra アカウントと個人用 Microsoft アカウントの両方でユーザーをサインインします。 V2 API に切り替えると、V1 Microsoft Entra 構成を使用して Microsoft ID プラットフォーム プロバイダーが構成されます。 V1 Microsoft アカウント プロバイダーは移行プロセスで引き継がれ、通常どおり動作し続けますが、新しい Microsoft ID プラットフォーム モデルに移行する必要があります。 詳細については、「 Microsoft Entra プロバイダーへの構成の切り替え」を参照してください。

自動移行プロセスでは、プロバイダー シークレットをアプリケーション設定に移動し、残りの構成を新しい形式に変換します。 自動移行を使用するには:

  1. ポータルでアプリに移動し、左側のウィンドウで >認証] を選択します。
  2. アプリが V1 モデルで構成されている場合は、[ アップグレード ] ボタンが表示されます。
  3. [アップグレード]ボタンを選択します。 確認プロンプトで説明を確認します。 移行を実行する準備ができたら、プロンプトで [アップグレード] を選択します。

移行を手動で管理する

次の手順では、前に説明した自動バージョンを使用しない場合に、アプリケーションを V2 API に手動で移行できます。

シークレットをアプリケーション設定に移動する

ID プロバイダー シークレットをアプリケーション設定に移動するには、次の手順を実行します。

  1. V1 API を使用して既存の構成を取得します。

    az webapp auth show -g <group_name> -n <app_name>

    結果の JSON ペイロードで、構成した各プロバイダーに使われるシークレット値を記録しておきます。

    • Microsoft Entra: clientSecret
    • グーグル： googleClientSecret
    • Facebook： facebookAppSecret
    • X： twitterConsumerSecret
    • Microsoft アカウント: microsoftAccountClientSecret

    重要

    シークレット値は重要なセキュリティ資格情報であり、慎重に扱う必要があります。 これらの値を共有したり、ローカル コンピューターに保持したりしないでください。

  2. シークレット値ごとにスロットに固定されたアプリケーション設定を作成します。 各アプリケーション設定の名前を選択できます。 その値は、前の手順で取得した値と一致するか、その値で作成した Azure Key Vault シークレットを参照 する必要があります。

    この設定を作成するには、Azure portal を使用するか、プロバイダーごとに次のコマンドのバリエーションを実行します。

    # For web apps, Google example    
az webapp config appsettings set -g <group_name> -n <app_name> --slot-settings GOOGLE_PROVIDER_AUTHENTICATION_SECRET=<value_from_previous_step>

# For Azure Functions, X example
az functionapp config appsettings set -g <group_name> -n <app_name> --slot-settings TWITTER_PROVIDER_AUTHENTICATION_SECRET=<value_from_previous_step>

    注記

    この構成のアプリケーション設定はスロットスティッキーとしてマークする必要があります。つまり、 スロット スワップ操作中に環境間を移動しません。 認証構成が環境に関連付けられているため、この構成が必要です。

  3. authsettings.json という名前で新しい JSON ファイルを作成します。 前に受け取った出力を取得し、そこから各シークレット値を削除します。 残りの出力をファイルに追加し、シークレットが含まれていないことを確認します。 場合によっては、構成に空の文字列を含む配列が含まれている場合があります。 microsoftAccountOAuthScopesが含まれていないことを確認します。 その場合は、値を null に変更します。

  4. 前の手順で作成した各プロバイダーのアプリケーション設定名を指すプロパティを authsettings.json に追加します。

    • Microsoft Entra: clientSecretSettingName
    • グーグル： googleClientSecretSettingName
    • Facebook： facebookAppSecretSettingName
    • X： twitterConsumerSecretSettingName
    • Microsoft アカウント: microsoftAccountClientSecretSettingName

    この操作の後の設定ファイルは次のようになります。この場合、Microsoft Entra ID 用にのみ構成されます。

    {
    "id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/myresourcegroup/providers/Microsoft.Web/sites/mywebapp/config/authsettings",
    "name": "authsettings",
    "type": "Microsoft.Web/sites/config",
    "location": "Central US",
    "properties": {
        "enabled": true,
        "runtimeVersion": "~1",
        "unauthenticatedClientAction": "AllowAnonymous",
        "tokenStoreEnabled": true,
        "allowedExternalRedirectUrls": null,
        "defaultProvider": "AzureActiveDirectory",
        "clientId": "00001111-aaaa-2222-bbbb-3333cccc4444",
        "clientSecret": "",
        "clientSecretSettingName": "MICROSOFT_IDENTITY_AUTHENTICATION_SECRET",
        "clientSecretCertificateThumbprint": null,
        "issuer": "https://sts.windows.net/aaaabbbb-0000-cccc-1111-dddd2222eeee/",
        "allowedAudiences": [
            "https://mywebapp.azurewebsites.net"
        ],
        "additionalLoginParams": null,
        "isAadAutoProvisioned": true,
        "aadClaimsAuthorization": null,
        "googleClientId": null,
        "googleClientSecret": null,
        "googleClientSecretSettingName": null,
        "googleOAuthScopes": null,
        "facebookAppId": null,
        "facebookAppSecret": null,
        "facebookAppSecretSettingName": null,
        "facebookOAuthScopes": null,
        "gitHubClientId": null,
        "gitHubClientSecret": null,
        "gitHubClientSecretSettingName": null,
        "gitHubOAuthScopes": null,
        "twitterConsumerKey": null,
        "twitterConsumerSecret": null,
        "twitterConsumerSecretSettingName": null,
        "microsoftAccountClientId": null,
        "microsoftAccountClientSecret": null,
        "microsoftAccountClientSecretSettingName": null,
        "microsoftAccountOAuthScopes": null,
        "isAuthFromFile": "false"
    }   
}

  5. このファイルをアプリの新しい認証/承認構成として送信します。

    az rest --method PUT --url "/subscriptions/<subscription_id>/resourceGroups/<group_name>/providers/Microsoft.Web/sites/<app_name>/config/authsettings?api-version=2020-06-01" --body @./authsettings.json

  6. ファイルを送信した後も、アプリが想定どおりに動作していることを確認します。

  7. 前の手順で使用したファイルを削除します。

これで、ID プロバイダーのシークレットをアプリケーション設定として格納するためにアプリが移行されました。

構成を Microsoft Entra プロバイダーに切り替える

既存の構成に Microsoft アカウント プロバイダーが含まれており、Microsoft Entra プロバイダーが含まれていない場合は、構成を Microsoft Entra プロバイダーに変更してから、移行を実行できます。

  1. Azure portal で アプリの登録 に移動し、Microsoft アカウント プロバイダーに関連付けられている登録を見つけます。 " 所有しているアプリケーション " という見出しの下にある場合があります。
  2. 登録の [認証 (プレビュー)] ページに移動します。 [ リダイレクト URI] の下に、 /.auth/login/microsoftaccount/callbackで終わるエントリが表示されます。 この URI をコピーします。
  3. コピーした URI と一致する新しい URI を追加しますが、最後に /.auth/login/aad/callback。 この URI を使用すると、登録を App Service の認証/承認構成で使用できます。
  4. ポータルでアプリに移動します。 [設定]>[認証]を選択します。
  5. Microsoft アカウント プロバイダーの構成を収集します。
  6. 高度な管理モードを使用して Microsoft Entra プロバイダーを構成し、前の手順で収集したクライアント ID とクライアント シークレットの値を指定します。 発行者 URL には、<authentication-endpoint>/<tenant-id>/v2.0を使用します。 <authentication-endpoint> をクラウド環境の認証エンドポイントに置き換えます (例: "https://login.microsoftonline.com"グローバル Microsoft Entra ID の場合)。 <tenant-id>をディレクトリ (テナント) ID に置き換えます。
  7. 構成を保存したら、ブラウザーでサイト上の /.auth/login/aad エンドポイントに移動し、サインイン フローを完了して、サインイン フローをテストします。
  8. この時点で、構成は正常にコピーされましたが、既存の Microsoft アカウント プロバイダーの構成は残ります。 削除する前に、アプリのすべての部分がサインイン リンクなどを通じて Microsoft Entra プロバイダーを参照していることを確認します。 アプリのすべての部分が想定どおりに動作することを確認します。
  9. すべてが Microsoft Entra プロバイダーで動作することを検証したら、Microsoft アカウント プロバイダーの構成を削除できます。

警告

Microsoft Entra アプリの登録で サポートされているアカウントの種類 を変更することで、2 つの登録を集約できます。 ただし、この構成では、Microsoft アカウント ユーザーに対して新しい同意プロンプトが強制されます。また、それらのユーザーの ID 要求は構造が異なる可能性があります。 sub 、新しいアプリ ID が使用されているため、特に値が変更されます。 十分に理解していない限り、このアプローチはお勧めしません。 代わりに、V2 API でこの 2 つの登録に対するサポートが提供されるのを待つことをお勧めします。

V2 に切り替える

前の手順を完了したら、Azure portal でアプリに移動します。 [ 認証 (プレビュー)] セクションを選択します。

または、サイト リソースの config/authsettingsv2 リソースに対して PUT 要求を行うことができます。 ペイロードのスキーマは、 ファイル ベースの構成でキャプチャされたものと同じです。

特定の認証ランタイム バージョンにアプリをピン留めする

認証と承認を有効にすると、機能の概要で説明されているように、プラットフォーム ミドルウェアが HTTP 要求パイプラインに挿入されます。 このプラットフォーム ミドルウェアは、定期的なプラットフォームの更新の一環として、新機能と機能強化で定期的に更新されます。 既定では、Web アプリまたは関数アプリは、このプラットフォーム ミドルウェアの最新バージョンで実行されます。 これらの自動アップデートは常に下位互換性を持っています。 ただし、まれに、この自動更新によって Web アプリまたは関数アプリにランタイムの問題が発生することがあります。その場合は、以前のミドルウェア バージョンに一時的にロールバックすることができます。 このセクションでは、認証ミドルウェアの特定のバージョンにアプリを一時的にピン留めする方法について説明します。

自動および手動でのバージョンの更新

アプリの runtimeVersion 設定を構成することで、特定のバージョンのプラットフォーム ミドルウェアにアプリをピン留めできます。 アプリは、特定のバージョンに明示的にピン留めしない限り、常に最新バージョンで実行されます。 一度にサポートされるバージョンがいくつかあります。 サポートされなくなった無効なバージョンにピン留めした場合、アプリでは代わりに最新バージョンが使用されます。 常に最新バージョンを実行するには、 runtimeVersion を ~1 に設定します。

現在のランタイム バージョンの表示と更新

アプリで使用されるランタイム バージョンを変更できます。 アプリを再起動すると、新しいランタイム バージョンが有効になります。

現在のランタイム バージョンの表示

Azure CLI を使用するか、アプリの組み込みバージョンの HTTP エンドポイントのいずれかを使用して、プラットフォーム認証ミドルウェアの現在のバージョンを表示できます。

Azure CLI から

Azure CLI を使用して、 az webapp auth show コマンドを使用して現在のミドルウェア バージョンを表示します。

az webapp auth show --name <my_app_name> \
--resource-group <my_resource_group>

このコードでは、<my_app_name> をアプリの名前に置き換えます。 <my_resource_group>をアプリのリソース グループの名前に置き換えます。

CLI の出力に runtimeVersion フィールドが表示されます。 次の出力例に似ていますが、わかりやすくするために切り捨てられます。

{
  "additionalLoginParams": null,
  "allowedAudiences": null,
    ...
  "runtimeVersion": "1.3.2",
    ...
}
バージョンエンドポイントから

アプリの /.auth/version エンドポイントをヒットして、アプリが実行されている現在のミドルウェア バージョンを表示することもできます。 出力は次のようになります。

{
"version": "1.3.2"
}

現在のランタイム バージョンの更新

Azure CLI では、runtimeVersion コマンドを使用して、アプリの設定を更新できます。

az webapp auth update --name <my_app_name> \
--resource-group <my_resource_group> \
--runtime-version <version>

<my_app_name> をご自分のアプリの名前に置き換えます。 <my_resource_group>をアプリのリソース グループの名前に置き換えます。 <version>を有効なバージョンの 1 に置き換えます。x ランタイム、または最新バージョンの~1を使用します。 Azure Functions 用にピン留めするバージョンを確認するには、 Azure Functions ランタイムバージョンの概要に関するページを参照してください。

このコマンドは、前のコードサンプルでOpen Cloud Shellを選択することでAzure Cloud Shellから実行できます。 az login を実行してサインインした後、Azure CLI をローカルで使用してこのコマンドを実行することもできます。

次のステップ

チュートリアル:エンドツーエンドでのユーザーの認証と承認

  • Last updated on