Having used OAuth on several occasions as a client (accessing Facebook/Twitter/LinkedIn/GitHub etc), it was naturally the first option that came to mind for securing my API.
My requirements right now are simple:
- I am experimenting building an Android mobile app that will use a server API (webapp & API will be built using Java & Spring stack)
- The app I am experimenting is mobile-only (no web client)
- It is not going to become a public API (e.g. won't be supporting other apps/sites)
I guess the key point is that I only intend to expose the API to my mobile app, and not have lots of comsumers of the API - and given the complexity of implementing OAuth, it seemed like it would be overkill as a solution. A big benefit of OAuth is that it supports client/application keys.
So I started looking around for other ideas as to how to do this - I was (and still am) curious as to how Twitter/Instagram secure their APIs for their own applications - I know that the Twitter API is secured for public use using OAuth, but the interesting question is how they secure their own application key/secret. The problem with mobile apps is that an application key needs to be stored on the device - and whilst Twitter offers severely throttled API access using OAuth (register an application, get a secret app key etc), their own apps are obviously not throttled, so it seems like it would be a challenge to keep their application key secured, as if its in the app code, then its subject to de-compilation.
Anyway, getting close to resigning to the fact that I was going to have to use OAuth I came across this one-pager from Google. The guide suggests a much simplified approach with the following basic steps:
- Build an webapp on your server that has a login page
- From your mobile app, embed a WebView of the login page
- Upon login to your app, return a cookie with a token value that can be used to log in your user on future requests - ideally re-using your frameworks Remember-Me type services so not to have to hand-roll your own
- On every API request include the token in your request header to authenticate (again using the Remember Me services)
The fact that it was a suggested approach from Google is pretty good, and it's a tonne simpler than negotiating the OAuth dance, so I thought I would have a look at getting this setup.
This is all good - but really, the advice to use OAuth is a half-truth, as if you ever have to scale your application, and think you might one day have/want to open it up do other developers/clients then OAuth is the way to go - You won't get much love from third-party developers with a non-standard approach to securing your API.
So.. how can it be done with Spring? I will cover that in my next post later this/next week!
OUATH is a delegated identity authorization protocol with 4 participants. I believe, one has to have an authentication layer on top of it if you'd like to leverage OUTH like for eg:; openId connect. I'm not sure whether you can do authentication with OUTH alone. Authentication can also be done using protocols like STS, SAML (within enterprise), PKI. At this point, we've a requirement to authenticate subject using multi-factor authentication from devices like mobile. Please share inputs if you've been able to do it with OUTH as i can easily secure end-point resources like SOA implementation using REST using CMS (container managed security) using Authorization header (Basic, Digest, client-cert) etc., Which authorization grant are you planning to use to authenticate subject?
ReplyDelete