Frost Matthew. - Integrating Web Services with OAuth and PHP

February 2016

For everyone whos helped me along the way, especially Chris Hartjes, Matt Turland, Yitzchok Wilroth, Beth Tucker Long, Tyler Etters, Nick Escobedo, and Jeff Carouth.

I became a Facebook user back when it was still exclusive to college students, before it became a platform for third-party applications. Not long after I graduated, I also became an early adopter of Twitter. This was in the days before OAuth, when the API used Basic HTTP authentication and many users would provide their username and password to third parties to try out the latest new app or client. Those were simpler times with a nave and yet blissful ignorance about them.

I still remember using dial-up internet for the first time and being amazed at the possibilities of a world-wide network when Id only ever seen a few machines wired together to play games over a local area network. The Internet has grown up a great deal since then, and weve had to grow with it. Once we got over the excitement of our new found ability to share information and the vast possibilities that lay therein, a critical realization followed: we also needed the ability to protect our information from those who would use it for less than noble purposes.

This grew ever more important as applications continued to evolve and increase in complexity, to the point where they would be used to identify us to third parties and share our information with them. At that point, we needed the ability to selectively grant those third parties access to our information without giving up the proverbial keys to the kingdom: our account credentials.

All it took was one nefarious or even innocently misbehaving app to wreak havoc with your account. You could reset your password, of course, but that would revoke access to your account for all other apps you used. HTTP authentication was no longer sufficient for the purposes of applications in this situation. A better solution was needed, and Twitter led the charge with OAuth 1 when it became a published standard in 2010.

While it paved the way forward for a standard to solve this class of problem, OAuth 1 had its drawbacks. The signature process it used in lieu of SSL was complex and made writing clients cumbersome. It lacked workflows for applications beyond those involving communication between two web applications, such as desktop and mobile. OAuth 2 would succeed it only two years later after the issues with it became apparent.

In the midst of all these technological developments, I had the good fortune to become acquainted with Matt Frost through the PHP community and the PHP Mentoring program. We began our relationship as mentor and apprentice, but became friends and even co-workers at one point.

Ive believed for some time that everyone is in a position to be both a student and a teacher to others. Matt has proven that by writing this book and reversing the nature of our original relationship to make me the student, as the books subject has been one that Ive personally struggled with since OAuth first became a standard.

I hope youll follow me in allowing the words that Matt has written to dispel the magic that may surround OAuth for you as it has for me. While you continue to witness the evolution of the internet and all its technological wonders, I hope you will also be mindful of how it can best benefit humankind.

Matthew Turland
New Orleans, LA
June 24, 2014

Its no secret the Internet is everywhere; it powers a large amount of the software we use every single day. An explosion of Application Programming Interfaces (APIs) has significantly increased the number of different services that can be integrated into a single piece of software. In spite of these obvious observations, one thing has remained constant: HTTP (HyperText Transfer Protocol) is the backbone of the Internet. Since the days when browsers were rendering sparkly star backgrounds underneath a myriad of randomly placed images, HTTP has been the protocol responsible for serving up (thankfully, not creating) these web pages.

In order to build applications which are responsive and useful for the end user, its important to understand HTTP and the structure of the requests, as well as the responses they generate. Though it may seem trivial for static web sites and applications with minimal functionality, in todays world of highly integrated web applications understanding the protocol is a necessity. An understanding of HTTP allows other systems and developers to interact with our code in a logical way and accelerates the development process. HTTP is a collection of rules for transferring text, images, videos, and sounds in addition to other file and data types across the web via the transmission of requests and responses. Much like linguistic communication, a browser or server will request a specific resource from a web server; the request will also provide specific details to ensure the response can be delivered the way the requesting server expects. The server receiving the request will attempt to act on the specific details of the request and will report back to the requestor whether or not their request could be fulfilled and return any pertinent information regarding the request. Thats a pretty high level overview of how HTTP generally works; if you would like more detail you can read through the HTTP/1.1 RFC .

This chapter will focus on the very basics of HTTP. It is not intended to be an exhaustive resource on the topic, but should provide enough information to gain a better understanding of how OAuth works in the context of an application.

We all interact with authentication and authorization on a daily basis. In fact, most of the time it has nothing to do with the code you write or the applications you use. If you have a keypad on your garage, a swipe card to enter the office, or a debit card with a Personal Identification Number (PIN) then you are constantly authorizing transactions and actions. We are also aware of the risks and precautions we need to take to ensure that information isnt disseminated. Losing your swipe card, debit card, or PIN can lead to unauthorized users gaining access to your finances or place of employment. Your garage code can lead to your house being vandalized, burgled, or worse. We treat these scenarios as serious security breaches, as we should. If were smart, our PIN isnt the same as our garage code and doesnt contain any other personal information that can be used to gain access to other systems.

We have the same risks and should be taking equally effective precautions with interacting with applications on the internet. As more of our daily lives have moved online we appreciate the convenience, but dont always consider the legitimate security risks (or the impact) breaches can have on our professional and personal lives. What it comes to down to is being as certain as possible that when our online accounts, application accounts and residential security systems authorize access, were the person initiating those requests. Imagine the outrage if your bank made your PIN available through relatively little effort. As application developers, we need to take great care to ensure the authorizing information our users trust us with is effectively protected.

Most applications these days require you to login with a user name and password. Its more common than not for users to have accounts on multiple web sites providing a myriad of different services. Some applications have leveraged this fact and allow you to login with credentials from popular services like Facebook, Twitter, and GitHubto name a few. While this is usually quite convenient, it should make us wonder Am I giving my Facebook credentials to another website?