Identity Server 4 and ASP.NET Core Identity

Question

A project I’m working on consists of a web API, a single page react application, and a mobile application. From each client, the user would need to supply their username and password in order to access protected parts of the web API. I’ve set up an Identity Server 4 authentication server that uses my own implementation of the IProfileService and IResourceOwnerPasswordValidator interfaces because I’m using ASP.NET Core Identity. This allows Identity Server to access the ASP.NET Core Identity UserManager, RoleManager, and SignInManagers to determine if the supplied username and password is valid.

The grant type I have been using for all of this is the “ResourceOwnerPassword” type. I haven’t totally integrated authorization into the single page app, but I can pass a user’s username and password to the identity server and a token is generated that I can add to the header of a request to my API.

I’ve done more research about Identity Server and related technologies because I’m new to all of this. It seems like it is undesirable to use the ResourceOwnerPassword grant type. From what I can tell it seems like I should be using the Implicit grant type, but I don’t fully understand how usernames and passwords fit into that flow. Does anyone have any insight into which type I should be using? Is the system I described only possible using ResourceOwnerPassword grant type?

Answer 1

The resource owner password grant type has this written about it on the IdentityServer docs:

The resource owner password grant type allows to request tokens on behalf of a user by sending the user’s name and password to the token endpoint. This is so called “non-interactive” authentication and is generally not recommended.

There might be reasons for certain legacy or first-party integration scenarios, where this grant type is useful, but the general recommendation is to use an interactive flow like implicit or hybrid for user authentication instead.

(Emphasis is mine)

All other flows involve redirects: the user clicks login on your website and is redirected to an identity server login page instead, they enter their credentials there and then are redirected back to your original webpage.

This is the same using your Google account, for example, to log in to other websites. Google wouldn't want you to enter that users name and password into your own site, because you could steal them, and this is generally why the resource owner password grant type is discouraged. But if you are doing a first-party integration (i.e. the website is yours, and you trust yourself with the user entering their password on your website) then I don't see what the problem is.

You should have a read (and look at the examples) for the other flows/grant types. They definitely have their place and I am not dismissing them, but if you are doing a first party integration then what are doing should be fine.