次の方法で共有


ASP.NET Core を使用した Microsoft アカウントの外部ログインのセットアップ

作成者: Valeriy NovytskyyRick Anderson

このサンプルでは、前のページで作成した ASP.NET Core 6.0 プロジェクトを使用して、ユーザーが自分の職場、学校、または個人の Microsoft アカウントでサインインできるようにする方法を示します。

Microsoft 開発者ポータルでアプリを作成する

Microsoft アカウントがない場合は、 [作成] を選択します。 サインインすると、 [アプリの登録] ページにリダイレクトされます。

  • [新しい登録] を選択します
  • [名前] を入力します。
  • [サポートされているアカウントの種類] のオプションを選択します。
    • MicrosoftAccount パッケージは、既定では、"任意の組織のディレクトリ内のアカウント" または "任意の組織のディレクトリ内のアカウントと Microsoft アカウント" オプションを使用して作成されたアプリ登録をサポートしています。
    • その他のオプションを使用するには、Microsoft アカウント認証の初期化に使用する MicrosoftAccountOptionsAuthorizationEndpointTokenEndpoint のメンバーに、作成後の [アプリの登録] の [エンドポイント] ページ ( [概要] ページで [エンドポイント] をクリックすると表示される) に表示される URL を設定します。
  • [リダイレクト URI] に、/signin-microsoft を追加した開発 URL を入力します。 たとえば、「 https://localhost:5001/signin-microsoft 」のように入力します。 このサンプルの後半で構成する Microsoft 認証スキームは、OAuth フローを実装するための /signin-microsoft ルートでの要求が自動的に処理されます。
  • [登録] を選択します

クライアント シークレットを作成する

  • 左側のウィンドウで、[証明書とシークレット] を選択します。
  • [クライアント シークレット] で、 [新しいクライアント シークレット] を選択します
    • クライアント シークレットの説明を追加します。
    • [追加] ボタンを選びます。
  • [クライアント シークレット] で、クライアント シークレットの値をコピーします。

URI セグメント /signin-microsoft は、Microsoft 認証プロバイダーの既定のコールバックとして設定されます。 MicrosoftAccountOptions クラスの継承された RemoteAuthenticationOptions.CallbackPath プロパティを使用して Microsoft 認証ミドルウェアを構成する場合は、既定のコールバック URI を変更できます。

Microsoft クライアント ID とシークレットを格納する

Secret Manager を使用して、[アプリの登録] の [概要] ページにある Microsoft アプリケーション (クライアント) ID や、[証明書とシークレット] ページで作成したクライアント シークレットなどの機密設定を格納します。 このサンプルでは、次の手順を使用します。

  1. シークレット ストレージを有効にする」の指示に従って、シークレット ストレージのプロジェクトを初期化します。

  2. 秘密キーの Authentication:Microsoft:ClientIdAuthentication:Microsoft:ClientSecret を使って、機密設定をローカル シークレット ストアに格納します。

    dotnet user-secrets set "Authentication:Microsoft:ClientId" "<client-id>"
    dotnet user-secrets set "Authentication:Microsoft:ClientSecret" "<client-secret>"
    

: の区切り記号は、すべてのプラットフォームの環境変数階層キーには対応していません。 __(ダブルアンダースコア)は、

  • すべてのプラットフォームに対応しています。 たとえば、:: の区切り記号には対応していませんが、__ には対応しています。
  • 自動で : に置換されます。

Microsoft アカウント認証を構成する

Program に認証サービスを追加します。

var builder = WebApplication.CreateBuilder(args);
var services = builder.Services;
var configuration = builder.Configuration;

services.AddAuthentication().AddMicrosoftAccount(microsoftOptions =>
    {
        microsoftOptions.ClientId = configuration["Authentication:Microsoft:ClientId"];
        microsoftOptions.ClientSecret = configuration["Authentication:Microsoft:ClientSecret"];
    });

AddAuthentication(IServiceCollection, String) オーバーロードは、DefaultScheme プロパティを設定します。 AddAuthentication(IServiceCollection, Action<AuthenticationOptions>) オーバーロードを使用すると、認証オプションを構成でき、これを使用してさまざまな目的に既定の認証スキームを設定できます。 以降の AddAuthentication への呼び出しで、前に構成した AuthenticationOptions プロパティがオーバーライドされます。

認証ハンドラーを登録する AuthenticationBuilder 拡張メソッドは、認証スキームごとに 1 回のみ呼び出すことができます。 スキームのプロパティ、スキーム名、および表示名の構成を可能にするオーバーロードが存在します。

Microsoft アカウント認証でサポートされる構成オプションの詳細については、MicrosoftAccountOptions API リファレンスを参照してください。 これは、ユーザーに関するさまざまな情報を要求するために使用できます。

Microsoft アカウントでサインイン

  • アプリを実行し、 [ログイン] を選択します。 Microsoft でサインインするためのオプションが表示されます。
  • Microsoft でのサインインを選択します。 認証のために Microsoft にリダイレクトされます。 Microsoft アカウントでサインインすると、アプリがお客様の情報にアクセスできるようにすることを求めるメッセージが表示されます。
  • [はい] を選択します。 自分のメールを設定できるサイトにリダイレクトされます。

これで Microsoft の資格情報を使用してログインしました。

複数の認証プロバイダー

アプリが複数のプロバイダーを必要とする場合、AddAuthentication の背後にあるプロバイダーの拡張メソッドをチェインします。

services.AddAuthentication()
    .AddMicrosoftAccount(microsoftOptions => { ... })
    .AddGoogle(googleOptions => { ... })
    .AddTwitter(twitterOptions => { ... })
    .AddFacebook(facebookOptions => { ... });

プロキシまたはロード バランサーによる要求情報の転送

アプリがプロキシ サーバーまたはロード バランサーの背後に展開されると、元の要求情報の一部が要求ヘッダー内でアプリに転送される場合があります。 通常、この情報にはセキュアな要求スキーム (https)、ホスト、およびクライアント IP アドレスが含まれます。 アプリでは、これらの要求ヘッダーを自動的に読み取って、元の要求情報を検出して使用することはありません。

スキームは、外部プロバイダーによる認証フローに影響を及ぼすリンクの生成に使用されます。 セキュアなスキーム (https) が失われると、アプリでは、安全ではない不正なリダイレクト URL が生成されます。

Forwarded Headers Middleware を使用して、アプリが要求を処理する際に元の要求情報を利用できるようにします。

詳細については、「プロキシ サーバーとロード バランサーを使用するために ASP.NET Core を構成する」を参照してください。

トラブルシューティング

  • Microsoft アカウント プロバイダーによってサインイン エラー ページにリダイレクトされた場合は、URI の # (ハッシュタグ) の直後に続くエラー タイトルと説明のクエリ文字列のパラメーターをメモします。

    エラー メッセージは Microsoft 認証に関する問題を示しているようですが、最も一般的な原因は、アプリケーション URI が Web プラットフォームに指定されているリダイレクト URI と一致しないことです。

  • ConfigureServicesservices.AddIdentity を呼び出して Identity が構成されていない場合、認証しようとすると、"ArgumentException: The 'SignInScheme' オプションを指定する必要があります" になります。 このサンプルで使用するプロジェクト テンプレートによって、これが完了したことが確実になります。

  • 最初の移行を適用してサイト データベースが作成されていない場合は、"要求エラーの処理中にデータベースの操作に失敗しました" が表示されます。 [移行の適用] をタップしてデータベースを作成し、更新するとエラーが解消されます。

次の手順

  • この記事では、Microsoft で認証する方法を示しました。 同様の方法で、前のページに一覧されている他のプロバイダーでも認証できます。
  • Web サイトを Azure Web アプリに発行したら、Microsoft 開発者ポータルで新しいクライアント シークレットを作成します。
  • Azure portal で Authentication:Microsoft:ClientIdAuthentication:Microsoft:ClientSecret をアプリケーション設定として設定します。 構成システムは、環境変数からキーを読み取るように設定されています。

このサンプルでは、前のページで作成した ASP.NET Core 3.0 プロジェクトを使用して、ユーザーが自分の職場、学校、または個人の Microsoft アカウントでサインインできるようにする方法を示します。

Microsoft 開発者ポータルでアプリを作成する

Microsoft アカウントがない場合は、 [作成] を選択します。 サインインすると、 [アプリの登録] ページにリダイレクトされます。

  • [新しい登録] を選択します
  • [名前] を入力します。
  • [サポートされているアカウントの種類] のオプションを選択します。
    • MicrosoftAccount パッケージは、既定では、"任意の組織のディレクトリ内のアカウント" または "任意の組織のディレクトリ内のアカウントと Microsoft アカウント" オプションを使用して作成されたアプリ登録をサポートしています。
    • その他のオプションを使用するには、Microsoft アカウント認証の初期化に使用する MicrosoftAccountOptionsAuthorizationEndpointTokenEndpoint のメンバーに、作成後の [アプリの登録] の [エンドポイント] ページ ( [概要] ページで [エンドポイント] をクリックすると表示される) に表示される URL を設定します。
  • [リダイレクト URI] に、/signin-microsoft を追加した開発 URL を入力します。 たとえば、「 https://localhost:5001/signin-microsoft 」のように入力します。 このサンプルの後半で構成する Microsoft 認証スキームは、OAuth フローを実装するための /signin-microsoft ルートでの要求が自動的に処理されます。
  • [登録] を選択します

クライアント シークレットを作成する

  • 左側のウィンドウで、[証明書とシークレット] を選択します。
  • [クライアント シークレット] で、 [新しいクライアント シークレット] を選択します
    • クライアント シークレットの説明を追加します。
    • [追加] ボタンを選びます。
  • [クライアント シークレット] で、クライアント シークレットの値をコピーします。

URI セグメント /signin-microsoft は、Microsoft 認証プロバイダーの既定のコールバックとして設定されます。 MicrosoftAccountOptions クラスの継承された RemoteAuthenticationOptions.CallbackPath プロパティを使用して Microsoft 認証ミドルウェアを構成する場合は、既定のコールバック URI を変更できます。

Microsoft クライアント ID とシークレットを格納する

Secret Manager を使用して、[アプリの登録] の [概要] ページにある Microsoft アプリケーション (クライアント) ID や、[証明書とシークレット] ページで作成したクライアント シークレットなどの機密設定を格納します。 このサンプルでは、次の手順を使用します。

  1. シークレット ストレージを有効にする」の指示に従って、シークレット ストレージのプロジェクトを初期化します。

  2. 秘密キーの Authentication:Microsoft:ClientIdAuthentication:Microsoft:ClientSecret を使って、機密設定をローカル シークレット ストアに格納します。

    dotnet user-secrets set "Authentication:Microsoft:ClientId" "<client-id>"
    dotnet user-secrets set "Authentication:Microsoft:ClientSecret" "<client-secret>"
    

: の区切り記号は、すべてのプラットフォームの環境変数階層キーには対応していません。 __(ダブルアンダースコア)は、

  • すべてのプラットフォームに対応しています。 たとえば、:: の区切り記号には対応していませんが、__ には対応しています。
  • 自動で : に置換されます。

Microsoft アカウント認証を構成する

Microsoft アカウント サービスを Startup.ConfigureServices に追加します。

public void ConfigureServices(IServiceCollection services)
{
    services.AddDbContext<ApplicationDbContext>(options =>
        options.UseSqlServer(
            Configuration.GetConnectionString("DefaultConnection")));
    services.AddDefaultIdentity<IdentityUser>(options => options.SignIn.RequireConfirmedAccount = true)
        .AddEntityFrameworkStores<ApplicationDbContext>();
    services.AddRazorPages();

    services.AddAuthentication().AddMicrosoftAccount(microsoftOptions =>
    {
        microsoftOptions.ClientId = Configuration["Authentication:Microsoft:ClientId"];
        microsoftOptions.ClientSecret = Configuration["Authentication:Microsoft:ClientSecret"];
    });
}

AddAuthentication(IServiceCollection, String) オーバーロードは、DefaultScheme プロパティを設定します。 AddAuthentication(IServiceCollection, Action<AuthenticationOptions>) オーバーロードを使用すると、認証オプションを構成でき、これを使用してさまざまな目的に既定の認証スキームを設定できます。 以降の AddAuthentication への呼び出しで、前に構成した AuthenticationOptions プロパティがオーバーライドされます。

認証ハンドラーを登録する AuthenticationBuilder 拡張メソッドは、認証スキームごとに 1 回のみ呼び出すことができます。 スキームのプロパティ、スキーム名、および表示名の構成を可能にするオーバーロードが存在します。

Microsoft アカウント認証でサポートされる構成オプションの詳細については、MicrosoftAccountOptions API リファレンスを参照してください。 これは、ユーザーに関するさまざまな情報を要求するために使用できます。

Microsoft アカウントでサインイン

アプリを実行し、 [ログイン] を選択します。 Microsoft でサインインするためのオプションが表示されます。 [Microsoft] を選択すると、認証のために Microsoft にリダイレクトされます。 Microsoft アカウントでサインインすると、アプリがお客様の情報にアクセスできるようにすることを求めるメッセージが表示されます。

[はい] をタップすると、メールを設定できる Web サイトにリダイレクトされます。

これで Microsoft の資格情報を使用してログインしました。

複数の認証プロバイダー

アプリが複数のプロバイダーを必要とする場合、AddAuthentication の背後にあるプロバイダーの拡張メソッドをチェインします。

services.AddAuthentication()
    .AddMicrosoftAccount(microsoftOptions => { ... })
    .AddGoogle(googleOptions => { ... })
    .AddTwitter(twitterOptions => { ... })
    .AddFacebook(facebookOptions => { ... });

プロキシまたはロード バランサーによる要求情報の転送

アプリがプロキシ サーバーまたはロード バランサーの背後に展開されると、元の要求情報の一部が要求ヘッダー内でアプリに転送される場合があります。 通常、この情報にはセキュアな要求スキーム (https)、ホスト、およびクライアント IP アドレスが含まれます。 アプリでは、これらの要求ヘッダーを自動的に読み取って、元の要求情報を検出して使用することはありません。

スキームは、外部プロバイダーによる認証フローに影響を及ぼすリンクの生成に使用されます。 セキュアなスキーム (https) が失われると、アプリでは、安全ではない不正なリダイレクト URL が生成されます。

Forwarded Headers Middleware を使用して、アプリが要求を処理する際に元の要求情報を利用できるようにします。

詳細については、「プロキシ サーバーとロード バランサーを使用するために ASP.NET Core を構成する」を参照してください。

トラブルシューティング

  • Microsoft アカウント プロバイダーによってサインイン エラー ページにリダイレクトされた場合は、URI の # (ハッシュタグ) の直後に続くエラー タイトルと説明のクエリ文字列のパラメーターをメモします。

    エラー メッセージは Microsoft 認証に関する問題を示しているようですが、最も一般的な原因は、アプリケーション URI が Web プラットフォームに指定されているリダイレクト URI と一致しないことです。

  • ConfigureServicesservices.AddIdentity を呼び出して Identity が構成されていない場合、認証しようとすると、"ArgumentException: The 'SignInScheme' オプションを指定する必要があります" になります。 このサンプルで使用するプロジェクト テンプレートによって、これが完了したことが確実になります。

  • 最初の移行を適用してサイト データベースが作成されていない場合は、"要求エラーの処理中にデータベースの操作に失敗しました" が表示されます。 [移行の適用] をタップしてデータベースを作成し、更新するとエラーが解消されます。

次の手順

  • この記事では、Microsoft で認証する方法を示しました。 同様の方法で、前のページに一覧されている他のプロバイダーでも認証できます。
  • Web サイトを Azure Web アプリに発行したら、Microsoft 開発者ポータルで新しいクライアント シークレットを作成します。
  • Azure portal で Authentication:Microsoft:ClientIdAuthentication:Microsoft:ClientSecret をアプリケーション設定として設定します。 構成システムは、環境変数からキーを読み取るように設定されています。