OAuth 2.0/2.1 - Resource Owner Password Credentials grant alternative

Question

We have a number of Web API 2.0 REST APIs, all of which are available over https, that are used by a small number of our customers. Access to the APIs is restricted by IP address, ie they provide a client IP to us on agreeing with our T&Cs. On designing the APIs, we reviewed OAuth 2.0, and we decided to implement the Resource Owner Password Credentials (ROPC) grant. It was deemed to be the best fit. On calling our '/token' endpoint, with their username and password, the credentials are authenticated, and authorization is granted. An access token is issued for three hours. The client id and secret associated with the resources are not exposed to the client at any point. The client attaches the access token to the header of the requests that they make to the remaining endpoints.

On reviewing OAuth 2.1, we noticed that the ROPC grant has been omitted. We are happy to replace the ROPC with the Authorization Code Grant, most likely, but that is going to take some time to implement, test etc. I've been discussing this with another ex-colleague of mine, and his team are in a similar position to us. They use ROPC for their REST APIs, but they are not locked down by client IP. They are also going to replace the ROPC also, but they are thinking about changing the manner in which the username and passwords are sent to their '/token' endpoint, in the interim. The are considering Base64 encoding, where the credentials are formatted as follows '{username}-{password}', or similar. Is their any value in implementing this? He is arguing that obfuscation of the username and password makes it worthwhile.

Answer 1

You should aim to get on a standard path and avoid non standard options. The answer depends on these questions:

QUESTIONS

• What types of client do you have?
• Are you using an Authorization Server or home grown OAuth?
• Are your stakeholders happy to pay for changes?

TECHNICAL ANSWERS

• B2B clients. Use the Client Credentials Grant. This is pretty easy and in future you can make the client secret a stronger credential providing Mutual TLS. Technical migration from ROPC is easy.

• UI Clients. The direction here is Authorization Code Flow (PKCE). However, this has a prerequisite of doing OAuth in the recommended way: using an Authorization Server, integrating libraries to handle complex messages and so on. The technical migration can therefore be a lot more expensive.

At the very least it is worth understanding the flows so that you can plan ahead.