1, Foreword
This article has been updated to. NET Core 2.2
OAuth 2.0 resource owner password mode allows the client to send a user name and password to the token service and obtain an access token on behalf of the user.
In addition to applications that cannot interact through a browser, it is generally not recommended to use the resource owner password mode. In general, using one of the interactive OpenID Connect processes is much better when you want to authenticate users and request access tokens.
This pattern is used here to learn how to use it quickly in identity server,
2, Add user
Just like API resources (also known as Scope) and clients, users also have an in memory based implementation.
For details on how to properly store (persistent storage) and manage user accounts, see the ASP.NET Quick start to identity.
The TestUser class represents the test user and its identity information unit (Claim). Let's create several users by adding the following code to the config class:
First add the following statement to Config.cs In the file:
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" } }; }
Then register the test user to IdentityServer:
public void ConfigureServices(IServiceCollection services) { // configure identity server with in-memory stores, keys, clients and scopes services.AddIdentityServer() .AddInMemoryApiResources(Config.GetApiResources()) .AddInMemoryClients(Config.GetClients()) .AddTestUsers(Config.GetUsers()); }
The AddTestUsers method helps us do the following:
- Add support for resource owner password authorization
- Add support for user related services, which are usually used by login UI (we will use login UI in the next quick start)
- Add support for identity services based on test users (you'll learn more about it in the next quick start)
4, Add a client definition for resource owner password authorization
You can simply add support for existing client authorization types by modifying the properties of · AllowedGrantTypes >.
Usually you want to create a separate client for the resource owner use case, add the following code to the client definition in your configuration:
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" } } }; }
Request a token using password authorization
Create a ResourceOwnerPassword console project and add the IdentityModel package through Nuget
Get Token through the following code
// request token var tokenResponse = await client.RequestPasswordTokenAsync(new PasswordTokenRequest { Address = disco.TokenEndpoint, ClientId = "ro.client", ClientSecret = "secret", UserName = "alice", Password = "password", Scope = "api1" }); if (tokenResponse.IsError) { Console.WriteLine(tokenResponse.Error); return; } Console.WriteLine(tokenResponse.Json);
When you send a token to an identity API endpoint, you notice a small but important difference from the client mode. The access token will now contain a sub claim that uniquely identifies the user. You can see this "sub" by checking the content variable after the API is called, and the controller application will also display the claim on the screen.
The presence (or absence) of sub claim allows the API to distinguish between calls on behalf of the client and those on behalf of the user.
The following figure shows the client request process,
For the supplementary explanation of the above figure, let's talk about it here. After the api resource receives the first request, it will go to the id4 server public key, and then use the public key to verify whether the token is legal. If it is legal, it will carry out the later validation. There is and only the first request will go to id4 server to request the public key, and later requests will be verified with the first request public key, which is also the idea of jwt decentralized verification.
5, Debugging with Postman
To generate token interface by using postman call, the following parameters need to be configured:
Last github address: https://github.com/stulzq/IdentityServer4.Samples/tree/master/Quickstarts/2_ResourceOwnerPasswords If you think it's useful for you, welcome star