Why shouldn't I use the OAuth password grant if I have to implement a custom username+password login anyway?

Question

I'm building a web REST API. Users must be able to authenticate themselves to this API.

I don't know ahead of time which clients will want to use the API. I want to allow for the possibility of anyone creating their own client, like a custom web frontend application or a native mobile app, for example. I don't need to support confidential clients (clients with client secrets) but not sure if that matters. My purpose in using OAuth is that it provides a mechanism for authorizing these clients to acts on behalf of users, without the clients ever seeing a user's password. It seems like OAuth fits well for this.

However, in order to use OAuth, some client must first authenticate with username and password, in order to be able to provide consent to other clients (you can't provide consent without authenticating as the consenting user after all). So I must have some way for a client to authenticate via username and password. Otherwise there is no way to start the OAuth flow in the first place.

So if that is the case, why not use the OAuth password grant type? I know that it is deprecated, but the only alternative I see is to implement my own custom login API route which would essentially work in exactly the same way. So I fail to see how the fact that I am or am not using it has any impact on the security of the system.

The password grant type does not seem to support 2-factor authentication, which is an issue. But I'd need to support it in some custom fashion in my login form anyway, so I still see it as better to use OAuth with some kind of 2FA extension on top, rather than a fully-custom login flow.

Am I misunderstanding something or is OAuth perhaps not a good fit for this use case somehow? Is there a better way to achieve what I want?

Answer 1

The mistake you're making is that you assume the component which asks for the user credentials is yet another OAuth client, which would indeed lead to a conundrum where one client has to use the Password grant to then allow passwordless authorization/authentication for the other clients.

However, the authentication component is not an OAuth client. It's a part of the authorization server.

For example, if the Authorization Code Grant type is used, then the client who wants access to a resource first redirects the resource owner to the authorization server. The authorization server then somehow authenticates the resource owner and asks whether resource access should be granted to the client. How exactly the authentication procedure looks like isn't defined in OAuth – it could be a classical log-in form asking for a username/e-mail and a password, it could be a page which triggers TLS client certificate authentication, it could be some 2FA solution. This is entirely up to you. After the authorization server has both authenticated the user and established consent, it hands over an authorization code to the client through a redirect.

When you understand that resource owner authentication isn't the job of an OAuth client, it should be clear that no client ever needs to see the owner's credentials. The Resource Owner Password Credentials Grant type is therefore unnecessary in most cases and should be avoided, because it turns the client into an additional entity which knows the resource owner credentials.

Edit: Since it still doesn't seem to be clear why your approach is a bad idea and doesn't really work, I'll try to go into more details.

If I understand you correctly, you envision the following workflow.

+------+
| user | 
+------+
 |
sends password through log-in form
 |
 v
+----------------------------+
| SPA acting as OAuth client |
+----------------------------+
 |
forwards password through Password Grant
 |
 v
+----------------------+
| authorization server |
+----------------------+
 |
(now some non-OAuth magic happens to authorize the other clients)
 |
 v
+---------------+
| other clients |
+---------------+

What the workflow according to the OAuth protocol should look like instead (assuming Authorization Code Grant):

+------+
| user | 
+------+
 |
sends password through log-in form
 |
 v
+----------------------+
| authorization server |
+----------------------+
 |
sends Authorization Code (forwarded by user)
 |
 v
+--------+
| client |
+--------+

What's the difference, and why is your approach bad?

• You're redefining the OAuth roles and their responsibilities. In OAuth, authenticating users and granting clients access to a resource is the job of the authorization server. You've instead introduced a “master client” which also takes care of authentication and authorization. This is sloppy, redundant and makes the implementation more complex.
• Since you don't use the clients and the authorization server according to specification, you now need to add nonstandard steps to make your scheme work. For example, the idea of a “master client” which authorizes other clients doesn't exist in OAuth, so after the Password Grant has been checked by the authorization server, you need to somehow change the authorization status of all other clients as well. Maybe you send a bulk of access tokens around, maybe you let all clients share the same token – in any case, this has nothing to do with OAuth.
• As you can clearly see in the diagram, you've added an entirely unnecessary level of indirection. Instead of simply letting the user authenticate directly towards the authorization server, they have to send their password to the “master client” which then forwards it to the authorization server. This not only increases the complexity. It also means the “master client” is now an additional entity which knows the user password (besides the authorization server). OAuth is supposed to prevent this exact problem!
• The Password Grant is deprecated and has been completely removed in OAuth 2.1. If your entire scheme depends on this feature, there's clearly a design error.

Answer 2

I'm assuming that you mean "Resource Owner Password Credentials", defined in 1.3.3 of the OAuth RFC.

The recommended grant type for the app you describe would be the "Authorization Code" grant type. The difference between the 2 is that, in the password credentials grant type, the client would need to access the user's username and password in order to get an access token. With the authorization code grant type, on the other hand, the client never sees the user's username or password; the user authenticates separately with the authorization server, which passes back a short lived authorization code which the client then exchanges for an access token.

You're right in thinking OAuth is a good fit for your use case, because in both cases, the client has no need for the username and password once it has obtained the access token. But in the password grant type the client does need to access the username and password to obtain the access token.

Note also the separation of the roles of resource server (your API) and authorization server (the thing that authenticates users and issues tokens) - it doesn't have to be your API that authenticates users (and sees their password).