Google has built a new version of its OAuth Playground tool for OAuth 2.0 (see Figure 8-1). The OAuth 2.0 Playground demonstrates the three-step process for a typical server-side web application Authorization Code flow: getting an authorization code, exchanging it for an access token, and making API requests. It also supports the Implicit flow for client-side web applications.

While the default configuration is to use Google’s APIs and OAuth endpoints, the tool does enable you to specify a custom client ID, client secret, and custom endpoints. Salesforce has blogged about how to use the tool with their APIs.

Figure 8-1. Google’s OAuth Playground

Google’s endpoint for the Check ID step of OpenID Connect can be used to validate any OAuth 2.0 token issued by Google. The endpoint at https://www.googleapis.com/oauth2/v1/tokeninfo is a simple read-only API. To get the scope and expiration date of a token, make a HTTP request to the endpoint and pass an OAuth access token as the access_token query parameter or an ID token as the id_token parameter.

The Apigee Console enables exploring APIs from 20+ API providers, such as Facebook, Twitter, Salesforce, and SoundCloud. For those APIs supporting OAuth, it performs a typical OAuth flow, though without exposing the protocol-level details of the OAuth exchange. After OAuth authorization is granted using a variety of versions of the OAuth 1.0 and OAuth 2.0 draft specifications, it provides easy access to call APIs by selecting prepopulated endpoint URLs. With each API request, the console displays the detailed HTTP request and response details.

Facebook provides an Access Token Tool, which issues access tokens that can be used for testing and debugging. Both user-based and app-based tokens are issued. The user tokens issued by the tool are similar to those issued by the server-side Web Application flow or client-side flow. The app tokens issued by the tool are similar to those issued by the Client Credentials flow.

They also provide an Access Token Debugger, which displays information about OAuth access tokens, including the scopes, validity, issue time, expiration time and more.

Many major API providers build and maintain client libraries for accessing their specific services. Some of these libraries, such as the Google API Clients and Facebook SDKs provide built-in support for OAuth 2.0. When OAuth support is provided, these libraries often abstract the implementations enough to make it really easy to implement.

Here are some API-specific client libraries which implement OAuth 2.0:

Some of these libraries make it trivially easy to implement OAuth 2.0. Here’s an example using Google’s Python library on App Engine with the library’s decorator pattern. This example requires only a few lines of OAuth-specific code:

from oauth2client.appengine import OAuth2Decorator
...
decorator = OAuth2Decorator(
    client_id='CLIENT_ID_FROM_DAILYMOTION',
    client_secret='CLIENT_SECRET_FROM_DAILYMOTION',
    scope='read',
    auth_uri='https://api.dailymotion.com/oauth/authorize',
    token_uri='https://api.dailymotion.com/oauth/token'
    )

class MainHandler(webapp.RequestHandler):

  @decorator.oauth_required
  def get(self):

    http = decorator.http()
    resp, content = http.request('https://api.dailymotion.com/me')

    path = os.path.join(os.path.dirname(__file__), 'welcome.html')
    logout = users.create_logout_url('/')
    variables = {
        'content': content,
        'logout': logout
        }
    self.response.out.write(template.render(path, variables))
...

If you’re looking to implement OAuth 2.0 across a wide variety of services, access your own services with OAuth authorization, or make requests to APIs provided without client libraries, you should consider using an open source library for OAuth 2.0.

Since the specification is still under active development, these libraries each support different versions of the draft specification.

Supporting draft 10, several of the OAuth 2.0 implementations in the Google API client libraries are also available as separate libraries:

Additional libraries for other languages are available on oauth.net.

In this Getting Started book, we have given you an overview of how OAuth 2.0 works for obtaining authorized access to user data and why it is important to improve security and user productivity. As an application developer, you should now understand the different authorization flows available and how to decide between them when an API provider supports multiple flows. We’ve also introduced OpenID Connect, discussed how it builds on top of the OAuth 2.0 protocol to enable user authentication, and some of the different security properties of authentication versus authorization. We hope the protocol-level foundation provided by this book will make you a better developer, even if you end up using libraries that abstract many of the details.

As you use OAuth 2.0 in your application, there are additional considerations you should take into account to optimize user experience and performance. When getting access to a user’s data, you should explore how requests for different levels of access and the timing of those requests affect approval rates. When authenticating users with OpenID Connect, you should think about which identity providers to support, how you deal with users who have accounts on multiple identity providers, how to improve sign-in performance by decoding the id_token JWT, and other potential factors that could decrease customer service tickets.

We primarily focused on the perspective of acting as an OAuth client. Many application developers may wish to open up their data by building OAuth-authorized API resource servers and running their own authorization servers. The knowledge you gained from this book should hopefully make it easier to understand the detailed specifications and security considerations documents that are referenced in the Appendix A and are important reading for API providers launching OAuth 2.0 authorized services.