The OAuth 2.0 resource owner password grant allows a client to send username and password
to the token service and get an access token back that represents that user.

The spec recommends using the resource owner password grant only for “trusted” (or legacy) applications.
Generally speaking you are typically far better off using one of the interactive
OpenID Connect flows when you want to authenticate a user and request access tokens.

Nevertheless, this grant type allows us to introduce the concept of users to our
quickstart IdentityServer, and that’s why we show it.

You could simply add support for the grant type to our existing client by changing the
AllowedGrantTypes property. If you need your client to be able to use both grant types
that is absolutely supported.

Typically you want to create a separate client for the resource owner use case,
add the following to your clients configuration:

The client looks very similar to what we did for the client credentials grant.
The main difference is now that the client would collect the user’s password somehow,
and send it to the token service during the token request.

When you send the token to the identity API endpoint, you will notice one small
but important difference compared to the client credentials grant. The access token will
now contain a sub claim which uniquely identifies the user. This “sub” claim can be seen by examining the content variable after the call to the API and also will be displayed on the screen by the console application.

The presence (or absence) of the sub claim lets the API distinguish between calls on behalf
of clients and calls on behalf of users.