Is OAuth always the right choice (and when isn't it)

Question

I am creating a mobile application which needs to interact on a per-user basis with an API. Having worked on several projects as a client of third-party APIs, my initial thought was to go with OAuth. However, I have been thinking about it, and I don't plan to open the API up publicly to other consumers - the only consumer will always only be my mobile app, so was thinking if OAuth is actually the best fit? Or is it overkill?

I then read this article advising on a process from Google, which suggests the following approach for exactly this scenario:

• Embed a webview in your app with a normal web based login form
• on successful login, pass secure cookie to mobile app which has secure token
• use token in future API requests

(assuming all over https etc)

This seems a lot simpler than any OAuth implementation, and could quite easily be done using Spring Security Filter/authentication chain (My server side code is Java & Spring MVC/Secutiry etc). It seems interesting that is the recommended approach from Google, which to my mind has added some credibility to the solution.

Assuming with the above solution I also included a mobile app key etc (just to stop any mobile hitting the form/API), it seems like it would have the same problem as OAuth in as much that I have to include my app key embedded in the mobile code (that could be decompiled etc).

I also read this article about the Amazon approach (apparently similar to an OAuth 1 implementation), which seems like it could be a reasonable extension to the google proposed solution above and rather than send the token to the server, use it as the key to hash the request data.

I am pretty new to implementing anything in security beyond normal web based user/password security - so would appreciate thoughts on when to use OAuth for mobile apps and if the above two solutions (amazon & google) are fit for purpose of if they have been superseded by OAuth 2.

Answer 1

The answer to the first part of the question is easy: no protocol is always the right choice.

OAuth solves (well, offers a solution to) a lot of little nagging problems like authorizing clients and protecting resources in a semi-granular way across browsers, active clients, and whatever is in between.

It can be overkill, which is a good reason not to use it. It doesn't do authentication (OpenID Connect is the authn extension to OAuth), and it doesn't offer certain behaviors that other protocols do, e.g. SAML, but on the other hand that might be a good thing.

The solution offered by Google has a lot of characteristics of OAuth, but relies heavily on the cookie, and doesn't look like it would scale well for public use. If you don't care about exposing the APIs publicly it might be fine, but if you ever want to then OAuth would be a better approach relative to that solution.

If you do go down the OAuth route you will likely want to support the latest version as that gives you access to OpenID Connect. Otherwise you're stuck building out your own means of authentication, and all clients will have to implement against your custom design.