In my last post, OAuth: Why it's good for API providers, I talked about why I recommend OAuth for API providers when they are exposing APIs for web or mobile apps.
This time, a short follow up to look at a couple of scenarios in which OAuth might not be the best solution.
APIs designed to be used only by servers.
When the only clients of your API are servers, OAuth is not the best solution. Having a separate set of authentication credentials for each app is a nice feature of OAuth, but for server-to-server use, the need to log in securely using a browser gets in the way.
Simply assigning a unique password to each app is probably sufficient. Two-way SSL is another good, albeit cumbersome approach.
I believe that OAuth is unnecessary for APIs that are used by a small number of internal or partner systems, and which are used by servers and not by end users who have passwords.
However, think ahead! If you discover that those APIs that are only accessed by servers today are useful by other types of clients (like web or mobile) tomorrow, then you'll need to support OAuth.
Are there other scenarios for which OAuth is unnecessary or even a bad idea?
Just like the server-to-server scenario, I think that OAuth doesn’t make sense in the following scenarios:
- Anything that requires commercial levels of trust. For example, when your security model requires the capabilities of a PKI infrastructure.
- One-time tokens. OAuth is a lot of complexity and machinery to make one API call.
Bad ideas include creating your own ‘version’ of OAuth or creating something that’s like OAuth but different. Sticking with standards, and focusing your development efforts on creating great apps seems like a better idea than rolling your own security scheme.
Next time: We'll talk about some OAuth complexities, and why it's worth the effort.