What Are The Oauth 2.0 Grant Types? Part IV: Resource Owner Credentials

If you’ve been following this blog post series on the different OAuth 2.0 grant types, you’ll know that we’ve already covered three of the four types: authorization code flow, implicit grant flow and client credentials. Congrats on making it this far!

We’re at the final grant type: resource owner credentials. This one is pretty simple in concept, but be aware I’ve left it for last for a good reason. If you take just one piece of information away from this post, let it be that this grant type should be avoided whenever possible.

Before we get into why you shouldn’t use resource owner credentials, let’s make sure we’re clear about what they are. Unlike in our last post on client credentials, where the credentials were those of some computer, resource owner credentials are those of a user. The user is the owner of the resource that is being shared, and typically those credentials are a username and password.

In other words, the owner of the resource is providing their own credentials for how they get access to that resource. And since OAuth is about sharing access to some protected resource, the resource owner credentials are used for a single request and are exchanged for an access token, which is then used to obtain access to a protected resource.

Okay, so you’re using resource owner password credentials directly as an authorization grant to obtain an access token. Credentials were used and in return the user has been authenticated.  This grant type can eliminate the need for the client to store the resource owner credentials for future use. So what’s the problem?

Keep in mind that choosing which OAuth 2.0 grant type to use depends on factors such as the level of security needed and the type of user experience you want to provide. The problem is that in most cases—and I would venture to say virtually all—the level of security needed is far above the level of security that the resource owner credentials grant type offers. It boils down to the fact that you’re giving up your very own credentials, and that’s not much improvement over the reason OAuth was created in the first place!

It’s important to understand that the resource owner credentials grant type is radically different from the other grant types. Those grant types are used either when requesting the end user to authenticate with a trusted third party, the authorization server (for the authorization code and implicit grant types), or for the special case where you know the client could safely protect a secret (the client credentials grant type). But having the end user authenticate with a trusted third-party server or service is radically different from having the end user hand over their own credentials to the resource server, where the special, protected resource is housed.

You’ve always been told not to share your password, and it applies here to the resource owner credentials grant type as well. Using resource owner credentials is just like sharing your password with a friend or colleague. Don’t do it!

Remember, by giving someone else your credentials, you’re putting the security risk in their hands. Will they store your password? Will they store it securely? How will those passwords be read? The list goes on and on as to all the possible security risks.

Here are a few cases where you might think you need to use this flow, but actually don’t.

1.  Device with no interface. When there’s no way to interact to sign in to the authorization server, you may want to say “I’ll just store my credentials on the device and have it sign in as me to get access to my resource.” In this case, instead you can use the device flow.
   
   
2.  A server in a server room if you haven’t overhauled everything to the cloud. When there’s no browser to prompt the user to authenticate, you may want to store your credentials on the device and have it sign in as you to get access to your resource. In this case, instead you can use the client credentials flow.
   
   
3.  IOT device. Similar to the first scenario, this device might not have an interface—or it could be like the second case and not have a browser to pull up an authentication screen. In this case, instead you can use the device flow. 
   
   
4.  A user signs in from their app. In the case of a user signing into their account from their app, instead you can use Authorization Code Flow with PKCE.  

So now that I’ve just laid out the case for why you shouldn’t use this grant type, you’re probably wondering why it even exists in the first place. Part of that is historical; people were (and still are) used to having usernames and passwords, and the OAuth spec improves upon this, albeit only slightly. And there’s a small benefit to sharing your credentials once per session, with the session being defined as the life of the access token, as opposed to simply sharing your credentials. Also, if it’s an isolated or strongly trusted system, the security risks are relatively low and using your own credentials might be okay.

PingOne for Customers does not support the Resource Owner Credentials grant type simply because it’s not safe and there’s always a better, safer option available. You have your choice of the other three grant types with simple API calls for each and the requests are ready to go with just a few config values in a Postman Collection. And you can keep up with the greatest and securest grant types with PKCE support baked into PingOne for Customers.

So best practices would dictate that you stay away from this grant type. In the meantime, I invite you to test out PingOne for Customers with a free trial!