ASP.NET Core を使用した Twitter の外部サインインのセットアップ

  • [アーティクル]

作成者: Valeriy Novytskyy、Rick Anderson

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

Note

以下で説明する Microsoft.AspNetCore.Authentication.Twitter パッケージには、Twitter が提供する OAuth 1a API を使っています。 その後、Twitter では、機能セットが異なる OAuth 2 API を追加しました。 AspNet.Security.OAuth.Twitter パッケージは、新しい OAuth 2 API を使うコミュニティ実装です。

Twitter でアプリを作成する

  • Microsoft.AspNetCore.Authentication.Twitter NuGet パッケージをプロジェクトに追加します。

  • Twitter Developer ポータルの Dashboard に移動して、サインインします。 まだ Twitter アカウントをお持ちでない場合は、 [今すぐサインアップ] リンクを使用して作成します。

  • プロジェクトがない場合は、作成します。

  • [+ Add app] (+ アプリの追加) を選択します。 アプリ名を入力し、生成された API キー、API キー シークレット、およびベアラー トークンを記録します。 これらは後で必要になります。

  • [App Settings] (アプリ設定) ページの [Authentication settings] (認証の設定) セクションで、[Edit] (編集) を選択し、次の手順を実行します。

    • 3 レッグの OAuth を有効にする
    • ユーザーの電子メール アドレスを要求する
    • 必須フィールドに入力し、[Save] (保存) を選択します

    注意

    Microsoft.AspNetCore.Identity では、既定で、ユーザーは電子メール アドレスを指定する必要があります。 開発中のコールバック URL については、https://localhost:{PORT}/signin-twitter を使用します。ここでは、{PORT} プレースホルダーはアプリのポートです。

    注意

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

Twitter コンシューマー API キーとシークレットを格納する

Secret Manager を使用して、Twitter のコンシューマー API キーやシークレットなどの機密設定を格納します。 このサンプルでは、次の手順を使用します。

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

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

    dotnet user-secrets set "Authentication:Twitter:ConsumerAPIKey" "<consumer-api-key>"
dotnet user-secrets set "Authentication:Twitter:ConsumerSecret" "<consumer-secret>"

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

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

これらのトークンは、新しい Twitter アプリケーションを作成した後の [Keys and Access Tokens](キーとアクセス トークン) タブにあります。

Twitter 認証を構成する

Startup.ConfigureServices に認証サービスを追加します。

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

    services.AddAuthentication().AddTwitter(twitterOptions =>
    {
        twitterOptions.ConsumerKey = Configuration["Authentication:Twitter:ConsumerAPIKey"];
        twitterOptions.ConsumerSecret = Configuration["Authentication:Twitter:ConsumerSecret"];
        twitterOptions.RetrieveUserDetails = true;
    });

}

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

services.AddAuthentication().AddTwitter(twitterOptions =>
    {
        twitterOptions.ConsumerKey = configuration["Authentication:Twitter:ConsumerAPIKey"];
        twitterOptions.ConsumerSecret = configuration["Authentication:Twitter:ConsumerSecret"];
    });

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

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

複数の認証プロバイダー

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

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

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

Twitter でのサインイン

アプリを実行し、 [ログイン] を選択します。 Twitter でサインインするためのオプションが表示されます。

[Twitter] を選択すると、認証のために Twitter にリダイレクトされます。

Twitter の資格情報を入力すると、ご利用の電子メールを設定できる Web サイトにリダイレクトされます。

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

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

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

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

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

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

トラブルシューティング

  • ASP.NET Core 2.x のみ:ConfigureServices で services.AddIdentity を呼び出して Identity が構成されていない場合、認証しようとすると、"ArgumentException: The 'SignInScheme' オプションを指定する必要があります" になります。 このサンプルで使用されているプロジェクト テンプレートを使用すると、Identity が確実に構成されます。
  • 最初の移行を適用してサイト データベースが作成されていない場合は、"要求エラーの処理中にデータベースの操作に失敗しました" が表示されます。 [移行の適用] をタップしてデータベースを作成し、更新するとエラーが解消されます。

次の手順

  • この記事では、Twitter を使って認証する方法について示しました。 同様の方法で、前のページに一覧されている他のプロバイダーでも認証できます。

  • Azure Web アプリに自分の Web サイトを発行したら、Twitter 開発者ポータルで ConsumerSecret をリセットする必要があります。

  • Azure portal で Authentication:Twitter:ConsumerKey と Authentication:Twitter:ConsumerSecret をアプリケーション設定として設定します。 構成システムは、環境変数からキーを読み取るように設定されています。