CODEWITHSUNDEEP
phpapiauthenticationoauth-2.0bcrypt
Harper
Harper

Reputation: 1305

OAuth 2 For Mobile Clients That I Own

I have a LAMP-stack webapp that exposes a REST API. The goal is to have 3 tiers - databse, services (REST), and multiple front-end clients (website, Android, iPhone). Currently, these tiers are all on the same box. The website uses the API to make calls to the service logic for CRUD operations, the mobile clients have not been built yet.

I am using a PHP bcrypt implementation, to store the user credentials. This is slow/CPU-intensive by design. Every API call takes a username/password pair along with the API parameters. This will impede large-scaling because the hash is computed with every API call.

So, I've been looking at alternatives. OAuth 2.0 uses revocable tokens which are not expensive to use, but articles I've read seem to suggest the primary use-case for this protocol is to let third-parties access my API. This does not quite fit my model as the mobile clients, for example, are owned by me.

  1. Is OAuth only meant to be used with third-parties or is it typical for a company to add its mobile clients as OAuth consumers for its own API?

  2. Is it okay to bundle a shared secret with an Android/iPhone app that I publish to the app market, so that they are immediately able to associate with the API?

Upvotes: 3

Views: 1029

Answers (1)

steve
steve

Reputation: 2008

oAuth v2 (http://oauth.net/2/) has a number of authentication patterns (6 in all) and although the "3 legged" scenario with end users authorizing 3rd party apps is the most visible it's definitely a good approach even if you own the apps.

You can potentially use a two legged flow like the trusted credentials flow https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-25#section-4.3. Basically in this you trust the client code (you wrote it) to receive and see the user's username and password and send it to your API. Once that's done, oAuth tokens are issues as normal and the password doesn't need to cross the connection again.

The second question on the shared secret - if your app always requires user login, then you might be able to avoid putting a shared secret into the app since your authentication relies on user credentials (in this case just put an ID in the app so you know which version it is). If the App operates without user login in some modes then you're likely to have little choice but to embed a secret of some kind at least for the init-steps.

Upvotes: 3

Related Questions