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

Discover how to focus on operators for Reactive Programming and how they are essential to react to data in your application.  Brought to you in partnership with Wakanda

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!

Learn how divergent branches can appear in your repository and how to better understand why they are called “branches".  Brought to you in partnership with Wakanda


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

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}