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.

  • I know this post is old, but you mentioned that Google link suggested embedding a webview in your app for oauth. As of now the link doesn't say that though. I just wanted to point out embedding a webview in your app is bad, the following RFC recommends always using the native browser: tools.ietf.org/html/rfc8252
    – Ian Newson
    Oct 15, 2018 at 20:57

1 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.

  • Thanks - so just to clarify, when you say the google solution wouldn't scale - are you saying that it wouldn't scale if I ever wanted to open up to third-party clients/websites, or wouldn't scale if my single consumer mobile app saw high growth of users (neither very likely!)
    – rhinds
    Mar 4, 2014 at 17:46
  • Also, any thoughts on whether hashing the request as per Amazon approach is worth the effort, so not to send the token with every request? or is that also overkill if i push everything over https?
    – rhinds
    Mar 4, 2014 at 17:46
  • 1
    Scale in the sense that developers would hate to use it because its non-standard. Making sure the message is signed does add the benefit of preventing tampering from MITM.
    – Steve
    Mar 4, 2014 at 17:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .