IdentityServer4 example uses the Resourceownerpassword process to protect the API

Using the Resourceownerpassword process to protect the API

The Resourceownerpassword authorization process in OAuth2.0 allows a client to send username and password to the token service to obtain an access token on behalf of the user.

It is recommended that this authorization type be used only for trusted clients in the specification. In general, you should use one of the processes in the OpenID Connect protocol (with authorization code, implicit, hybrid) to authenticate users and obtain access tokens in a scenario where user interaction occurs.

That being said, this type of authorization introduces the concept of a user in Identityserver, which is the only reason we want to show it.

Add user

Just like in-memory resources (or scopes) and clients, you can create in-memory users.

The TestUser class represents a test user and some of its declarations (claim). We now create some users in the Config class:

usingidentityserver4.test; Public StaticList<testuser>getusers () {return NewList<testuser>    {        NewTestUser {Subjectid="1", Username="Alice", Password="Password"        },        NewTestUser {Subjectid="2", Username="Bob", Password="Password"        }    };}

Then inject in the Configureservice method:

 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 ());}

The Addtestusers extension method does a few things in the background:

• Added support for resource owner password this type of authorization
• Added a user-related service that is typically used in the login UI.
• A profile service was added to the testuser.

Create a corresponding client for resource owner password this type of authorization

If you want the client to support both types of authorization, you can add support for this type of authorization by modifying the value of the Allowedgranttypes property on the existing client.

Typically you just want to create a separate client to use as resource owner password this type of authorization, add the following code to the Getclients method of the Config class:

 Public StaticIenumerable<client>getclients () {return NewList<client>    {        //Other clients omitted ...//Resource owner password Grant client        NewClient {ClientId="ro.client", Allowedgranttypes=Granttypes.resourceownerpassword, Clientsecrets=            {                NewSecret ("Secret". SHA256 ())}, Allowedscopes= {"api1" }        }    };}

Use password's authorization type to request token

The client defined above looks very much like the client credentials clients we defined earlier. The main difference is that the client now collects the user's password and sends it along with other things to the token service in the process of requesting token.

Use IdentityModel's tokenclient again to help us implement this request:

//Request TokenvarTokenclient =NewTokenclient (Disco. Tokenendpoint,"ro.client","Secret");varTokenresponse =awaitTokenclient.requestresourceownerpasswordasync ("Alice","Password","api1");if(Tokenresponse.iserror) {Console.WriteLine (tokenresponse.error); return;} Console.WriteLine (Tokenresponse.json); Console.WriteLine ("\ n");

When you send tokens to the API, you will find a very small and very important change (as opposed to the clientcredential type): Access token now contains a "sub" of the claim, This claim is a unique identifier (the Subjectid attribute of the testuser defined in the Config class is what is here), which is found in JSON that is returned by the method of the API. I am here to show 1 down, I passed postman:

The first is to access the API through the token obtained by the client credential this authorization, obtaining the following results:

[    {        "ClaimType":"NBF",        "Claimvalue":"1532508154"    },    {        "ClaimType":"Exp",        "Claimvalue":"1532511754"    },    {        "ClaimType":"ISS",        "Claimvalue":"http://localhost:5000"    },    {        "ClaimType":"AUD",        "Claimvalue":"http://localhost:5000/resources"    },    {        "ClaimType":"AUD",        "Claimvalue":"api1"    },    {        "ClaimType":"client_id",        "Claimvalue":"firstclient"    },    {        "ClaimType":"Scope",        "Claimvalue":"api1"    }]

Look at the statement without a sub.

Then use the resource owner password this authorization type to get tokens, and then use this token to access the API:

[    {        "ClaimType":"NBF",        "Claimvalue":"1532511508"    },    {        "ClaimType":"Exp",        "Claimvalue":"1532515108"    },    {        "ClaimType":"ISS",        "Claimvalue":"http://localhost:5000"    },    {        "ClaimType":"AUD",        "Claimvalue":"http://localhost:5000/resources"    },    {        "ClaimType":"AUD",        "Claimvalue":"api1"    },    {        "ClaimType":"client_id",        "Claimvalue":"secondclient"    },    {        "ClaimType":"Sub",        "Claimvalue":"2"    },    {        "ClaimType":"Auth_time",        "Claimvalue":"1532511508"    },    {        "ClaimType":"IDP",        "Claimvalue":"Local"    },    {        "ClaimType":"Scope",        "Claimvalue":"api1"    },    {        "ClaimType":"Amr",        "Claimvalue":"pwd"    }]

IdentityServer4 example uses the Resourceownerpassword process to protect the API