views:

402

answers:

1

I'm trying to find my way around the OAuth spec, its requirements and any implementations I can find and, so far, it really seems like more trouble than its worth because I'm having trouble finding a single resource that pulls it all together. Or maybe it's just that I'm looking for something more specialized than most tutorials.

I have a set of existing APIs--some in Java, some in PHP--that I now need to secure and, for a number of reasons, OAuth seems like the right way to go. Unfortunately, my inability to track down the right resources to help me get a provider up and running is challenging that theory. Since most of this will be system-to-system API usage, I'll need to implement a 2-legged provider. With that in mind...

  1. Does anyone know of any good tutorials for implementing a 2-legged OAuth provider with PHP?
  2. Given that I have securable APIs in 2 languages, do I need to implement a provider in both or is there a way to create the provider as a "front controller" that I can funnel all requests through?
  3. When securing PHP services, for example, do I have to secure each API individually by including the requisite provider resources on each?

Thanks for your help.

A: 

I would take a step back and think about what a properly authenticated client is going to be sending you.

Can you store the keys and credentials in a common database which is accessible from both sets of services, and just implement the OAuth provider in one language? When the user sends in a request to a service (PHP or Java) you then check against the common store. When the user is setting up the OAuth client then you do all of that through either a PHP or Java app (your preference), and store the credentials in the common DB.

There are some Oauth providers written in other languages that you might want to take a look at:

BrianLy
I could probably share a data store, but I assume that means that I have no choice but to implement the provider in multiple languages (or stand up a front controller, I suppose). From what (little) I understand of OAuth so far, I thought that might be the case, but was hoping to be wrong. On a similar note, it looks like I have to secure each API independently by including the necessary provider files (PHP). Is that correct? Feels awfully clunky.
Rob Wilkerson
After screwing with a PHP provider library for a day or so and getting nowhere, I decided that OAuth simply wasn't worth the aggravation. Marking this as the answer since it does provide some good information.
Rob Wilkerson