In OAuth: The valey key metaphor and OAuth: Flow for mobile apps, we talked about why OAuth is good for users - how it allows users to grant third-parties access to their web services or mobile apps without sharing their passwords.
This time, why OAuth is good for API providers whether they are exposing APIs for web apps or APIs designed for mobile apps.
OAuth means that Web apps that expose APIs don’t have to share passwords.
There are two alternatives
- The security risk of typing your password into every single web app you use – an unacceptable risk!
- Some sort of universal single sign-on mechanism (run by a third party that everyone agrees upon and trusts) – it doesn’t exist!
Therefore, for all web apps that expose APIs to other web apps - we recommend OAuth.
OAuth eliminates the need to store a password on a mobile device adding a layer of security when an API is used by mobile apps built by untrusted developers for a public API.
An OAuth token is hard to guess. It is tied to a particular app and device. It can be revoked without affecting other devices and apps.
OAuth allows the API provider to revoke tokens for an individual user, for an entire app, without requiring the user to change their original password. This is critical if a mobile device is compromised or if a rogue app is discovered.
OAuth future proofs the authentication process. Because users’ browsers are redirected to a place that’s under the control of the API team to get the OAuth token, the API team can control what to do at that point in the workflow.
In other words, OAuth is flexible enough to support any of your company’s specific workflows (think SSL, multi-factor authentication, terms of service, changes to terms of service, and so on…) without requiring a change to the client or server.
Therefore, for APIs designed for mobile and native apps – we recommend OAuth
Next time: OAuth in a server-to-server API scenario.