パスワードを使用したAPIの保護¶

OAuth 2.0のリソースオーナーパスワードの付与により、クライアントはユーザー名とパスワードをトークンサービスに送信し、そのユーザーを表すアクセストークンを取得できます。

この仕様では、「信頼できる」（または従来の）アプリケーションに対してのみ、リソース所有者のパスワード付与を使用することを推奨しています。一般に、ユーザーを認証してアクセストークンを要求する場合、対話型のOpenID Connectフローの1つを使用する方が、通常ははるかに優れています。

それにもかかわらず、このグラント・タイプは、ユーザーの概念をクイックスタートのIdentityServerに導入することを可能にします。

ユーザーの追加¶

リソース（別名スコープ）とクライアント用のメモリ内のストアと同様、ユーザー用のストアもあります。

注釈

ユーザーアカウントを適切に保存および管理する方法の詳細については、ASP.NET IDベースのクイックスタートを参照してください。

このクラスTestUserは、テストユーザーとその主張を表します。configクラスに次のコードを追加して、2人のユーザーを作成しましょう：

まず、次のusingステートメントをConfig.csファイルに追加します。:

using IdentityServer4.Test;

public static List<TestUser> GetUsers()
{
    return new List<TestUser>
    {
        new TestUser
        {
            SubjectId = "1",
            Username = "alice",
            Password = "password"
        },
        new TestUser
        {
            SubjectId = "2",
            Username = "bob",
            Password = "password"
        }
    };
}

次に、テストユーザーをIdentityServerに登録します。:

public void ConfigureServices(IServiceCollection services)
{
    // configure identity server with in-memory stores, keys, clients and scopes
    services.AddIdentityServer()
        .AddDeveloperSigningCredential()
        .AddInMemoryApiResources(Config.GetApiResources())
        .AddInMemoryClients(Config.GetClients())
        .AddTestUsers(Config.GetUsers());
}

AddTestUsers拡張メソッドは、ボンネットの下に物事のカップルを行います

リソース所有者のパスワード付与のサポートを追加
ログインUIによって通常使用されるユーザー関連サービスへのサポートを追加します（次のクイックスタートで使用します）
テストユーザーに基づくプロファイルサービスのサポートが追加されました（次回のクイックスタートで詳しく説明します）

リソース所有者のパスワード付与のためのクライアントの追加¶

AllowedGrantTypesプロパティーを変更することによって、既存のクライアントに許可タイプのサポートを追加することができます。あなたのクライアントが絶対にサポートされている両方の権限タイプを使用できるようにする必要がある場合。

通常、リソース所有者のユースケース用に個別のクライアントを作成し、クライアント構成に次のものを追加します。:

public static IEnumerable<Client> GetClients()
{
    return new List<Client>
    {
        // other clients omitted...

        // resource owner password grant client
        new Client
        {
            ClientId = "ro.client",
            AllowedGrantTypes = GrantTypes.ResourceOwnerPassword,

            ClientSecrets =
            {
                new Secret("secret".Sha256())
            },
            AllowedScopes = { "api1" }
        }
    };
}

パスワードの付与を使ってトークンを要求する¶

クライアントは、クライアントの資格認可のために行ったのと非常によく似ています。主な違いは、クライアントが何とかユーザーのパスワードを収集し、トークン要求中にトークンサービスに送信することです。

再びIdentityModel TokenClientがここで助けてくれるでしょう：

// request token
var tokenClient = new TokenClient(disco.TokenEndpoint, "ro.client", "secret");
var tokenResponse = await tokenClient.RequestResourceOwnerPasswordAsync("alice", "password", "api1");

if (tokenResponse.IsError)
{
    Console.WriteLine(tokenResponse.Error);
    return;
}

Console.WriteLine(tokenResponse.Json);
Console.WriteLine("\n\n");

トークンをID APIエンドポイントに送信すると、クライアントの資格認可と比較して小さいが重要な違いがあることに気づくでしょう。アクセストークンにはsub、ユーザーを一意に識別するクレームが含まれます。この「サブ」クレームは、APIへの呼び出し後にコンテンツ変数を調べることによって見ることができ、コンソールアプリケーションによって画面にも表示されます。

sub クレームの有無（または不在）により、APIはクライアントの代わりにコールを、ユーザーの代わりにコールを区別できます。