Lorna Mitchell has a new post to her blog today showing how to use the functionality provided by the pecl_http extension to make an OAuth2 connection to Google.

I've written about Google and OAuth before, but that was OAuth v1.0, and they are introducing OAuth2 for their newer APIs; in this example I was identifying myself in order to use the Google Plus API. [...] OAuth 2 doesn't need an extension or any particular library as it doesn't have the signing component that OAuth 1 had, and OAuth 2 also has fewer round trips. It does require SSL however, because the requests are in the clear.

She includes some code snippets with an example of a connection - making a request to the remote HTTPS resource, adding some parameters to the URL (including the response type, your client ID and a redirect url). The response then contains the "code" value you'll need to make the second request to fetch the access token you'll need on future requests. You can find out more about the interface she's accessing in these docs about the Google Plus API.

In a new post to his blog Sameer Borate shows how to create a lexer and parser in PHP to work directly with the tokens of a PHP script.

After looking around for a while [for a good resource on compilers] I settled for Terence Parr's Language Implementation Patterns. This is exactly what I needed - bit sized patterns on compiler and parser design with working code. The book provides a recipe style approach, gradually moving from simple to complex compiler/parser design issues. As I primarily work with PHP, I thought of porting some code to PHP to see how it works.

He shows examples using his custom tool to show a basic lexer output for a list and a complete listing of the code involved. Ultimately, though, he finds that PHP isn't overly suited to the task - anything more than his simple example could be more trouble than it's worth.

SitePoint' PHPMaster.com has a new tutorial posted today from Martin Psinas about some tactics to prevent cross-site request forgeries from happening in your PHP application. The article introduces key concepts of CSRF and how you can keep it from happening in your code.

Cross-site request forgery (CSRF) is a common and serious exploit where a user is tricked into performing an action he didn't explicitly intend to do. This can happen when, for example, the user is logged in to one of his favorite websites and proceeds to click a seemingly harmless link. In the background, his profile information is silently updated with an attacker's e-mail address. [...] Any action that a user is allowed to perform while logged in to a website, an attacker can perform on his/her behalf, whether it's updating a profile, adding items to a shopping cart, posting messages on a forum, or practically anything else.

He shows it to you "in action" with a PHP script for a basic login page that takes a username and password, does some filtering and sets the username to the session. Their "harmless.html" file offers a link to the site's "process" page with a logout action that would allow the "harmless" file access to the current session if clicked. To prevent this from happening, they suggest a unique token be included in interactions on your site. This key is checked against a token in the current session (or other location) and is only valid if they match.

The Symfony framework has included this as a part of their forms for a while now and includes automatic handling to check its validity. Solutions also exist for other frameworks like Zend Framework and many others.

Lorna Mitchell has posted the latest in her look at OAuth in PHP to her blog today, an introduction to access tokens - generating and handling them in your application.

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 thought I'd share my experience in this series of articles. [...] This entry follows on from the ones about the initial requirements, how to how to handle request tokens, and authenticating users.

In this latest post, she talks about the three different types of tokens - consumer, request and verififier - and how to use them to locate a user in your app's users. Her code validates the request token and verifier against the database and, if successful, inserts the rest of the token information for the user.

In a new post Stas Malyshev has shared some code for an OAuth provider he's written up to work specifically with Zend Framework applications.

Zend Framework has pretty good OAuth consumer implementation. However, it has no support for implementing OAuth provider, and it turns out that there aren't many other libraries for it. Most examples out there base on PECL oauth extension, which works just fine, with one caveat - you have to have this PECL extension installed, while ZF implementation does not require that. So I went ahead and wrote some code that allows to easily add OAuth provider to your ZF-based or ZF-using application. That should make writing OAuth provider easier.

His code just fleshes out the server portion of the provider, not all of the token generation and key handling it'll need on the backend - that'll still be the job of your scripts. You can find the library over on github in his Zend_OAuth_Provider repository.

Tim Lytle has written up a new tutorial for the Zend Developer Zone talking about OAuth and making one of the more difficult parts - getting an access token - a bit simpler using a command-line application.

OAuth is great - there's no need to save users' passwords, it's - in theory - a consistent way to interact with other services, and it's hopefully something that your users are familiar and comfortable using. But if you're not just interacting with your users' accounts - for example, your application uses a single account on a service to broadcast messages, or analyze data - getting or renewing the access token can be painful.

He illustrates the problem with an example connecting to Twitter and even points out a script that makes bridging this gap simpler. Unfortunately, it's not exactly what he needed, so he reworked the idea with a call to the Twitter API using a Zend_Oauth_Consumer and a custom callback. The script is then set up with some command line options for inputting the key and secret information. Also included is functionality letting you define a configuration file. You can see the final result here on github.

In the next of her series looking at OAuth in PHP, Lorna Mitchell has posted a look at request tokens and how to hand them out via your application.

The consumer requests a request token (see my earlier post about consuming OAuth), and as a provider, we need to handle that request. In my example, I chose to pass the variables as GET parameters, but you could adapt this to handle POST variables or information contained in HTTP headers.

She includes the code (using the functionality of the pecl_oauth extension) to provide a token and the three functions you'll need to define to get things working - the consumerHandler, the tokenHandler and timestampNonceHandler. She also includes a sample database table structure for storing the OAuth information for a user.

In a recent post to NetTuts.com, they show you how to protect your CodeIgniter application from cross-site request forgery (CSRF) attacks by using tokens in your forms and pages to make things more "one time" and unique to the site.

In today's tutorial, we will learn how to painlessly protect your CodeIgniter (pre 2.0) application against Cross-Site Request Forgery attacks. The library we'll be creating today will automate all of the protection mechanisms, making your site stronger and more secure.

They've broken it up into a few different sections to dole it out in easy to follow chunks:

• Understanding the Attack Vector
• Planning
• Token Generation
• Token Validation
• Inject Tokens into the Views
• Hooks

You can also download the full source of the library.

Lorna Mitchell has posted about her experiences with getting OAuth working with her PHP application by way of the PECL package that adds support into PHP.

I've been looking into OAuth recently and really like what I see, so I started looking at actually starting to play with something that uses it (and isn't twitter). In the pursuit of this, I spent some time walking through the process of how to actually authenticate using OAuth, as a client.

She briefly touches on the consumer key and secret and how those are passed along with the OAuth object creation to grab a request token, complete with details on setting a callback. She also mentions how to grab an access token - a piece of information you include in your API calls to let the remote service know who you are. All of her examples are using Yahoo! OAuth services.

In a recent post Hasin Hayder has taken a look at using the OAuth PECL extension (this one I assume) to connect your application's login system with Twitter's authentication backend.

if you are interested in developing twitter applications, you must have read about twitter API and it's authentication protocol. your application can fetch user's private data but it has to authenticate itself as the user for that. so there are two ways to do it: asking user to provide his twitter username and password [...] or let twitter handle the authentication on behalf of you.

This second option is where OAuth comes in. Once you've registered your application on Twitter, you can create a token and send it over to their site for validation. The idea is that, since the user has already authenticated on the Twitter site, they can allow an external application to "share" that login information/process and let the remote application fetch information about the user from he Twitter API.