Programming Social Applications

Conclusion

In this chapter, we have explored the simple process through which many providers traditionally allowed an application to access their services—the username and password login architecture of basic authentication. Although basic auth provided application developers with an incredibly easy, fast, and high-performance implementation backbone, it asked users to expose their personal login information through a username and password. When this type of architecture is mixed with external developers, there are bound to be security ramifications to exposing that data.

We then explored the two current OAuth implementations being used today, OAuth 1.0a and the emerging OAuth 2 standard. By examining workflow diagrams and sample implementations, we have seen firsthand the vast improvement these specifications represent over the basic authentication model. Working with tokens instead of user credentials puts control into the hands of the user—who can thus see who has access to their private data—and the provider that issued the tokens. Having this control means that if something malicious or unwanted happens in a client application, the user or provider can simply revoke the access token linking the user to the application.

The evolution of the OAuth standard demonstrates how open source authorization models are working to increase implementation and ease of use, encouraging adoption of the specification by reducing the complexity and effort required to implement it.