CODEWITHSUNDEEP
phpapisecurityoauth
galaxyAbstractor
galaxyAbstractor

Reputation: 557

OAuth for an API used by multiple services

I'm currently developing an API for phpBB as part of my Google Summer of Code project. The point of the API is to enable developers to create applications that connects to phpBB boards.

The user needs a proper way to authenticate (obviously it's a bad idea to have the user input his username and password directly into the application), and I've been considering multiple ways of doing this.

I've already done my own kind of implementation but people I've talked to says I should rather use OAuth. I've been reading up about OAuth for a week now but I'm not entirely sure how it should be used in this case. What I gather from three-legged OAuth is that the application developer has to register his application at the service to receive a consumer token prior getting a client token. This isn't really possible because the developer can't really register his application on all the phpBB boards.

I've been thinking about if the application automatically fetches a consumer token from the server then a client token but to me that sounds like it defeats the point of three-legged OAuth.

I've read a bit about two-legged OAuth but from what I gather you aren't supposed to use that as authentication and is more for internal applications??

The authentication system I've implemented so far is like this:

  1. Application requests an authentication token and a signing token from the phpBB board
  2. The user is prompted to visit the authentication page on the phpBB board with the tokens as parameters
  3. The application verifies with the phpBB board if the tokens are valid, the user would have to tell the application to do this after going trough the authentication phase in the browser
  4. When doing a request, say /api/forums/2/topics, the application would add the authentication token and a serial to the request: /api/forums/2/topics?auth_token=token&serial=2 where the serial is an everincreasing number to stop replay attacks. Then the application hashes the request using HMAC-SHA256 and appends it to the request as another GET parameter. The server does the same hashing to see if it's correct. This way attackers can't forge requests unless they got their hand on the signing token at the initial exchange.

I'm trying to figure out if I should rather try to implement OAuth instead of this, while trying to learn about OAuth. To be short: How would OAuth work spanning multiple services without having the developer register for each service?

Upvotes: 0

Views: 318

Answers (1)

John Sheehan
John Sheehan

Reputation: 78124

If there's no centralized service, OAuth is probably not the right choice. Even if you allowed devs to dynamically create the application entry for a given instance, they'd still need to be registered on each one themselves first so you know who to association the OAuth application too.

Maybe something like HTTP Signatures would suit your needs better?

Upvotes: 1

Related Questions