Over a million developers have joined DZone.

PHP OAuth Provider: Initial Requirements

DZone's Guide to

PHP OAuth Provider: Initial Requirements

· Web Dev Zone ·
Free Resource

Access over 20 APIs and mobile SDKs, up to 250k transactions free with no credit card required

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);

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!

#1 for location developers in quality, price and choice, switch to HERE.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}