PhpRiot
News Archive
PhpRiot Newsletter
Your Email Address:

More information

PHP OAuth Provider: Initial Requirements

Note: This article was originally published at Planet PHP on 10 May 2011.
Planet PHP
I've been working with OAuth, as a provider and consumer, and there isn't a lot of documentation around it for PHP at the moment so I'm sharing my experience in this series of articles. This relates to the stable OAuth 1.0a spec, however OAuth2 has already started to be adopted (and differs greatly). This article uses the pecl_oauth extension and builds on Rasmus' OAuth Provider post.

OAuth Pages and Endpoints



OAuth has a little more baggage with it than just passing a username and password to an API. As well as your standard service endpoint you will need:
  • A webpage for client applications to register for consumer key and secret

  • A request token endpoint

  • A webpage for users to log in to authorise consumers

  • An access token endpoint

  • A webpage for users to manage the applications they have granted access to


Consumer Registration



This is basically the client application registering for an API key. Each application only needs one of these, and both the consumer key and consumer secret are randomly-generated strings. There isn't a standard way or format for these, and the OAuth spec avoids giving guidelines. My advice would be to pick length and complexity appropriate for how critical your application data is, how trusted consumers are, and other such considerations. As an example, here's the code I'm using:

$hash = sha1(mt_rand());
$consumer_key = substr($hash,0,30);
$consumer_secret = substr($hash,30,10);
A

The consumer key is stored by both provider and consumer; the mysql table I'm using in my provider, looks like this:
desc oauth_consumers; +-----------------+-------------+------+-----+-------------------+ | Field | Type | Null | Key | Default | +-----------------+-------------+------+-----+-------------------+ | id | int(11) | NO | PRI | NULL | | consumer_key | varchar(30) | NO | | NULL | | consumer_secret | varchar(10) | NO | | NULL | | created_date | timestamp | NO | | CURRENT_TIMESTAMP | +-----------------+-------------+------+-----+-------------------+
You'd probably want to also store things like application name and some contact details for this app, the details will vary depending on what you are building and why.

In the next post I'll show off the code for the OAuthProvider and how to handle requests for a request token. Do add comments if you have anything to add/correct/comment on or whatever. I'm really interested to hear how others are working with these technologies!