Alex Koloskov
unread,Feb 23, 2012, 3:19:44 PM2/23/12Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to API Craft
I'm currently building a RESTful API to our web service, which will be
accessed by 3rd party web and mobile apps. We want to have certain
level of control over API consumers (i.e. those web and mobile apps),
so we can do API requests throttling and/or block certain malicious
clients. For that purpose we want every developer who will be
accessing our API to obtain an API key from us and use it to access
our API endpoints. For some API calls that are not dealing with the
specific user information, that's the only required level of
authentication & authorization, which I call "app"-level A&A. However,
some API calls deal with information belonging to the specific users,
so we need a way to allow those users to login and authorize the app
to access their data, which creates a second level (or "user"-level
A&A).
It makes a lot of sense to use OAuth2 for the "user"-level A&A and I
think I have a pretty good understanding of what I need to do here.
I also implemented OAuth1-like scheme, where app developers receive a
pair of API key & secret, supply their API key with every call and use
secret to sign their requests (again, it's very OAuth1 like and I
should probably just use OAuth1 for that).
Now the problem that I have is how to marry those two different
mechanisms. My current hypothesis is that I continue to use API key/
secret pair to sign all requests to be able to access all API
endpoints and for those calls that require access to user-specific
information apps will need to go through OAuth2 flow and obtain access
tokens and supply them.
So, my question to the community is - does it sounds like a good
solution or there are some better ways to architect this.
I'd also appreciate any links to existing solutions that I could use,
instead of re-inventing the wheel (our services is Ruby/Rails-based).