I downloaded the server version (PDO) available for the OAuth 2.0 here:
Not sure if it is the best implementation out there honestly.
It is configured and currently returns an error JSON indicating it is waiting for a client to pass it the correct arguments.
Now, it comes with a “lib” folder that has a Client .inc file. Honestly, I am not sure how to use it given there is no PHP example I found in the archive and couldn’t find anything online. I found an example for Drupal using this library, but it is a mess given they have their own Drupal-related functionalities as a module.
I was wondering if anyone here has had luck using this PHP client library, and if so can they share an example that connects, authorizes and then redirects to the callback URL with the session to be able to access protected page/api calls?
I wanted to try the Facebook Graph API (opensource), yet I found it very custom for Facebook and was not very sure where I should place the URL to the OAuth 2.0 server I installed on my own server machine.
Setting up an OAuth2 provider is rather easy once you know how the protocol works. It’s a 2-or-3 step process (depending on your set-up and whether you’re getting tokens on behalf of a user or just from the server).
What you’ll need:
- Working code for an OAuth2 provider
What you’ll need to figure out how to do on your code:
- Create a client (public and private access tokens)
- Figure out how the authorize and token endpoints are named (typically
- Figure out how the scopes are dealt with
The first step to getting a token is to call
/authorize?response_type=code&client_id=[YOUR ID]&redirect_uri=[YOUR REDIRECT URI]&scope=[YOUR SCOPE] , where:
- clientid ([YOUR ID]) is your public access token
- redirect_uri ([YOUR REDIRECT URI]) is your redirect URI. You will be redirected to this once you complete the autorize step
- scope is the scope of your future token
On completion (there’s usually a submit button), your browser will be redirected to the URI specified with a code in the URL (code=blah). Save this value.
When you’ve got this code, call the other endpoint:
/token?client_id=[YOUR ID]&client_secret=[YOUR SECRET]&grant_type=authorization_code&scope=[YOUR SCOPE]&code=[YOUR CODE]&redirect_uri=[YOUR REDIRECT URI]
– client_id – again, your client public key
– client_secret – your private key (this is supposed to be a server-side call)
– scope – the scope for the token – MUST MATCH THE FIRST CALL
– redirect_uri – the redirect URI – MUST MATCH THE FIRST CALL
– code – the code you received
If everything went okay, you’ll see a JSON object on your screen containing the token info.
What happens in the background
Step 1 (authorize)
When you confirm the form, the server creates a temporary token (auth token as they’re called), which typically has a very short life (my oauth2 sp code typically sets this to 60 seconds). This is the time your server has to go from receiving the code to triggering step 2. It is just a confirmation system, and its purpose is to also store the info provided in step 1 to prevent hijacks.
Step 2 (token)
This is where your access token is actually created. Lots of verifications, lots of stuff, but in the end, the token is just a value that links your client_id and your token. That’s all it is.
Shameless plug: if you’re using the Laravel framework, I’ve built exactly this from scratch (rather than using the crappy, undocumented sample code): http://bundles.laravel.com/bundle/oauth2-sp
PHP has a PECL client: http://www.php.net/manual/en/book.oauth.php
Nice intro on oauth2: http://www.slideshare.net/aaronpk/an-introduction-to-oauth-2
This site oauth2.net/2/ list out 3 oauth server in different stages of development.
Big providers (Facebook, Google, Yahoo, Twitter, etc) implements their own flavour of Oauth, and moreover Oauth 2.0 is still in draft revision, each provider follows a different revision
I’m working on some type of this PHP client which does the following:
- Listen on a socket
- Authentication -> Request
- Authentication Process -> Server Side Rules
- Authentication -> Response as result
- Continue Client Side demand on response gathered
Short answer is: curl + JSON
All authentication process requested with curl to my server-side script which takes authentication vars, then process and compare and at the end echo ‘JSON Encoded’ response contains multiple variables in echo returned to the client.
After response gathered ‘JSON Decode’ variables as independent var and now Client Side script know whatever do for this client.
Then give the currently authenticated user (specified by Sessions) some tools.
All work is executed in PHP Desktop, an embed mongoose web server with PHP and curl support.
In fact, it’s not necessary to use any lib so PHP has own complete library. Use curl, JSON and in server-side PHP, MySQL (conditional check) is enough for authentication purposes.
I’m partly confused by your question. You said that “It is configured and currently returns an error JSON indicating it is waiting for a client to pass it the correct arguments”, and yet you’re wanting an example of something that “connects, authorizes and then redirects to the callback URL”? If you have everything up and running and waiting to accept requests, you should be able to just use a jQuery Ajax request (using the authorization header) to make a request. So long as you have the appropriate client_id and client_secret plugged in it should return whatever you have your web API set up to dump out.
There is an error in the code for the pdo_oauth example. The secret key isn’t saved to the database, so that may be why you are having an issue.
Line 45 of pdo_oauth.php needs to be changed from:
$stmt->bindParam(":pw", $pw, PDO::PARAM_STR);
$stmt->bindParam(":pw", $secret, PDO::PARAM_STR);