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

Get deep insight into Node.js applications with real-time metrics, CPU profiling, and heap snapshots with N|Solid from NodeSource. Learn more.

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!

Node.js application metrics sent directly to any statsd-compliant system. Get N|Solid


Published at DZone with permission of Lorna Mitchell, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}