I developed a REST API whose clients are mobile apps/websites under my control (API is not open to anyone). Users log into my mobile app/website with their Facebook or g+ login. I'd like to secure the API so that either:

(a) users can access it only after successfully logging into fb/g+ via my app/website


(b) only my apps/websites can access it.

I came up with following for (a) and would appreciate feedback on any weaknesses or improvements:

  1. All data between mobile app and REST API are encrypted with TLS.
  2. User logs into my app with their Facebook/g+ credentials.
  3. App receives token from fb/g+ and retrieves user info.
  4. App sends user info (username/email/unique id) and token to REST API (e.g., /login).
  5. REST API uses token and unique id to make a test call to fb/g+ API to ensure token and user info combo are valid.
  6. REST API issues its own token to app and caches token keyed by unique id.
  7. App sends unique id and token with every subsequent access to REST API.
  8. REST API looks up unique id and token in cache. If it exists, API access is granted to that request.

I'd like to do away with step 5, but don't see how else to verify the credentials given to the REST API.

I also thought about using Basic HTTP Authentication and TLS for (b), and this would be fine for a website client, but for mobile apps, it means the password would have to be stored on the mobile app in some form and susceptible to exposure, wouldn't it? From what I gather, securing an API with Basic Auth and TLS is very common and I can see how it can work for websites, but I don't know of a way to achieve (b) for mobile apps without risking exposure of the password.


1 Answer 1

  1. your API may not be as public as you thought. One can sniff all of the traffic from the mobile and get all of the data sent from the mobile app to your server.

  2. even with htpps or basic auth, one can sniff the data.


  • The OP specifically identified TLS in use. Even assuming weak cipher suites were used, a MITM would generate cert errors which mobile platforms and most modern browsers will not ignore. The attacker would need a trusted cert to beat that, assuming cert pinning isn’t in use. So.. while MITM is technically possible, the OP has good mitigations in place.
    – user18519
    Commented Sep 18, 2018 at 16:16
  • The attacker would need a trusted cert to beat that --> I can install a fake cert on my mobile phone and sniff all of his API connections. that's why there is technically no "private" API.
    – keithics
    Commented Sep 19, 2018 at 3:24
  • Nothing fake about it, you can add a trusted CA of your own if you’re on iOS or a rooted android. But that will only work if he doesn’t use cert pinning. And there are significant security controls preventing a rogue app from doing that, barring an OS exploit.
    – user18519
    Commented Sep 19, 2018 at 3:33

You must log in to answer this question.

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