Getting Started with OAuth 2.0 (Ryan Boyd) (Z-Library)

📄 File Format: PDF

💾 File Size: 6.0 MB

📖 Read Online ⬇️ Download

Registered users can read the full content for free

Register as a Gaohf Library member to read the complete e-book online for free and enjoy a better reading experience.

📄 Page 1

(This page has no text content)

📄 Page 2

(This page has no text content)

📄 Page 3

Getting Started with OAuth 2.0 Ryan Boyd Beijing • Cambridge • Farnham • Köln • Sebastopol • Tokyo

📄 Page 4

Getting Started with OAuth 2.0 by Ryan Boyd Copyright © 2012 Ryan Boyd. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://my.safaribooksonline.com). For more information, contact our corporate/institutional sales department: (800) 998-9938 or corporate@oreilly.com. Editors: Mike Loukides and Shawn Wallace Production Editor: Teresa Elsey Cover Designer: Karen Montgomery Interior Designer: David Futato Illustrator: Robert Romano Revision History for the First Edition: 2012-02-17 First release See http://oreilly.com/catalog/errata.csp?isbn=9781449311605 for release details. Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of O’Reilly Media, Inc. Getting Started with OAuth 2.0, the image of a horned trunk fish, and related trade dress are trademarks of O’Reilly Media, Inc. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and O’Reilly Media, Inc., was aware of a trademark claim, the designations have been printed in caps or initial caps. While every precaution has been taken in the preparation of this book, the publisher and authors assume no responsibility for errors or omissions, or for damages resulting from the use of the information con- tained herein. ISBN: 978-1-449-31160-5 [LSI] 1329511012

📄 Page 5

Table of Contents Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 How OAuth Was Born 1 Why Developers Should Care About OAuth 2 Why Don’t These APIs Just Use Passwords for Authorization? 3 Terminology 4 Authentication 4 Federated Authentication 4 Authorization 4 Delegated Authorization 5 Roles 5 The Great Debate over Signatures 6 Mitigating Concerns with Bearer Tokens 6 Signing Your OAuth 2.0 Requests 7 Developer and Application Registration 7 Why Is Registration Necessary? 9 Client Profiles, Access Tokens, and Authorization Flows 9 Client Profiles 9 Access Tokens 10 Authorization Flows 11 2. Server-Side Web Application Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 When Should the Authorization Code Flow Be Used? 13 Security Properties 13 User Experience 15 Step-by-Step 15 Step 1: Let the user know what you’re doing and request authorization 15 Step 2: Exchange authorization code for an access token 20 Step 3: Call the API 23 Step 4a: Refresh the access token 25 iii

📄 Page 6

Step 4b: Obtaining a new access token 27 How Can Access Be Revoked? 27 3. Client-Side Web Applications Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 When Should the Implicit Grant Flow Be Used? 29 Limitations of the Implicit Grant Flow 29 Security Properties 30 User Experience 31 Step-by-Step 31 Step 1: Let the user know what you’re doing and request authorization 31 Step 2: Parsing the access token from the URL 32 Step 3: Call the API 33 Step 4: Refreshing the access token 34 How Can Access Be Revoked? 34 4. Resource Owner Password Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 When Should the Resource Owner Password Flow Be Used? 36 Security Properties 36 User Experience 36 Step-by-Step 36 Step 1: Ask the user for their credentials 37 Step 2: Exchange the credentials for an access token 37 Step 3: Call the API 39 Step 4: Refresh the access token 39 5. Client Credentials Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 When Should the Client Credentials Flow Be Used? 41 What APIs Support the Client Credentials Flow? 42 How Does the Client Authenticate? 42 Security Properties 42 Step-by-Step 42 Step 1: Exchange the application’s credentials for an access token 43 Step 2: Call the API 43 When the Access Token Expires 44 6. Getting Access to User Data from Mobile Apps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Why You Should Use OAuth for Native Mobile Apps 45 What Flow Should Be Used for Native Mobile Apps? 46 Do You Have a Mobile Backend Web Server for Your Application? 46 The (Ugly) Web Browser 47 Embedded WebView 47 System Web Browser 48 Enhanced Mobile App Authorization for Specific Providers 49 iv | Table of Contents

📄 Page 7

For Google 49 For Facebook 49 7. OpenID Connect Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 ID Token 52 Security Properties 52 Obtaining User Authorization 53 Check ID Endpoint 54 UserInfo Endpoint 55 Performance Improvements 56 Practical OpenID Connect 56 For Google 56 For Facebook 58 OpenID Connect Evolution 60 8. Tools and Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Google’s OAuth 2.0 Playground 61 Google’s TokenInfo Endpoint 61 Apigee’s Console 62 Facebook’s Access Token Tool and Access Token Debugger 62 Libraries 63 Going Further 64 Appendix: References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Table of Contents | v

📄 Page 8

(This page has no text content)

📄 Page 9

Preface I’ve been working with web-based APIs since 1999, building SOAP-based web services for internal IT applications and helping thousands of developers using Google’s REST- based APIs for Google Calendar, Picasa Web Albums, YouTube, and more. Each of these APIs has required authorization from users to act on their behalf. Developers using these Google APIs were initially required to use proprietary technologies like ClientLogin and AuthSub. If these same developers wanted to integrate with APIs pro- vided by Yahoo!, they needed to use Yahoo!’s BBAuth. The use of these proprietary authorization technologies made it challenging to build applications using APIs from multiple providers. The development of OAuth 1.0 reduced many of the headaches for developers and allowed them to use a single authorization technology across hundreds of APIs on the Web. However, OAuth 1.0 came with some challenges as well—cryptographic signa- tures and limited definition of how to use it for authorizing applications not using a server-to-server web application flow. I’m delighted that the standardization of OAuth 2.0 is nearly complete, as it provides an authorization protocol that’s easy to use both for these types of applications and for a variety of other use cases. Perhaps most exciting is the upcoming standardization of OpenID Connect—a proto- col built on top of OAuth 2.0 to enable using the same identity to log in (authenticate) to multiple applications. While I’ve worked with hundreds of developers who have successfully built earlier versions of OpenID authentication into their web applications, it’s rarely been a very smooth process. Just as OAuth 2.0 makes authorization easier for developers, OpenID Connect does the same for authentication. I hope this book gives you the foundation knowledge you need to work with OAuth 2.0 and OpenID Connect as the next-generation authorization and authenti- cation technologies for the Web. vii

📄 Page 10

Conventions Used in This Book The following typographical conventions are used in this book: Italic Indicates new terms, URLs, email addresses, filenames, and file extensions. Constant width Used for program listings, as well as within paragraphs to refer to program elements such as variable or function names, databases, data types, environment variables, statements, and keywords. Constant width bold Shows commands or other text that should be typed literally by the user. Constant width italic Shows text that should be replaced with user-supplied values or by values deter- mined by context. This icon signifies a tip, suggestion, or general note. This icon indicates a warning or caution. Using Code Examples This book is here to help you get your job done. In general, you may use the code in this book in your programs and documentation. You do not need to contact us for permission unless you’re reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing a CD-ROM of examples from O’Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of example code from this book into your product’s documentation does require permission. We appreciate, but do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: “Getting Started with OAuth 2.0 by Ryan Boyd (O’Reilly). Copyright 2012 Ryan Boyd, 978-1-449-31160-5.” If you feel your use of code examples falls outside fair use or the permission given above, feel free to contact us at permissions@oreilly.com. viii | Preface

📄 Page 11

Safari® Books Online Safari Books Online is an on-demand digital library that lets you easily search over 7,500 technology and creative reference books and videos to find the answers you need quickly. With a subscription, you can read any page and watch any video from our library online. Read books on your cell phone and mobile devices. Access new titles before they are available for print, and get exclusive access to manuscripts in development and post feedback for the authors. Copy and paste code samples, organize your favorites, down- load chapters, bookmark key sections, create notes, print out pages, and benefit from tons of other time-saving features. O’Reilly Media has uploaded this book to the Safari Books Online service. To have full digital access to this book and others on similar topics from O’Reilly and other pub- lishers, sign up for free at http://my.safaribooksonline.com. How to Contact Us Please address comments and questions concerning this book to the publisher: O’Reilly Media, Inc. 1005 Gravenstein Highway North Sebastopol, CA 95472 800-998-9938 (in the United States or Canada) 707-829-0515 (international or local) 707-829-0104 (fax) We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at: http://shop.oreilly.com/product/0636920021810.do To comment or ask technical questions about this book, send email to: bookquestions@oreilly.com For more information about our books, courses, conferences, and news, see our website at http://www.oreilly.com. Find us on Facebook: http://facebook.com/oreilly Follow us on Twitter: http://twitter.com/oreillymedia Watch us on YouTube: http://www.youtube.com/oreillymedia Preface | ix

📄 Page 12

Acknowledgments I’d like to thank the identity and auth teams at Google for providing years of guidance and expertise, and most importantly Eric Sachs, Marius Scurtescu, and Breno de Me- deiros for their review and feedback on this book. I also would like to thank my family, friends, and colleagues in Google’s Developer Relations group for their constant support. Of course, without the fantastic work of the OAuth spec authors and working groups, nobody would have a chance to use or write about OAuth. x | Preface

📄 Page 13

CHAPTER 1 Introduction How OAuth Was Born In the movie Ferris Bueller’s Day Off, a valet attendant takes a fully restored 1961 Ferrari out for a joyride. How do you prevent the same thing from happening to your brand- new Mustang? Some cars now come with special keys that allow the owner to provide limited authorization to valet attendants (or kids!) and prevent activities such as open- ing the trunk and driving at excessive speeds. OAuth was created to solve the same core issue online. When Google first released the Google Calendar API, it provided the ability for appli- cation developers to read and manipulate a user’s Google Calendar. However, the only way for a user to provide delegated access was to give the application his or her account username and password, which the application would then use with Google’s propri- etary ClientLogin protocol. Proprietary protocols like ClientLogin and standard protocols like HTTP Basic au- thentication resulted in both small and big applications requesting passwords from users to get access to their data. This wasn’t affecting just desktop apps—applications all over the Web were prompting for credentials. Flickr, an online photo-sharing site, was one such application. Originally an independent company, Flickr was acquired by Yahoo! a few years after Google bought Blogger. The idea of Yahoo! asking for Google user passwords scared both firms, leading to the development of new proprietary pro- tocols that tackled this problem on the Web. With these new protocols, such as Google’s AuthSub (see Figure 1-1) and Yahoo!’s BBAuth, an application would redirect users to an authorization page on the provider’s site if the app needed access to user data. Users would log in to their accounts and grant access, and then the application would get a token to use for accessing the users’ data. While this solved some security issues, it also created costs for developers. Developers integrating with multiple major API providers had to learn and implement several web-based authorization protocols in their applications. Startups building new APIs 1

📄 Page 14

were not comfortable implementing the proprietary auth schemes, nor developing their own custom schemes, which might introduce security vulnerabilities. Instead, these startups and major API providers decided that they needed to create a standard protocol to improve consistency for these web-based authorization flows. Why Developers Should Care About OAuth With wide adoption of collaboration platforms and social networks, application de- velopers have the opportunity to connect users with their data wherever they are on the Web. Connecting users with their data results in improved day-to-day efficiency by eliminating data silos and also allows developers to differentiate their applications from the competition. OAuth provides the ability for these applications to access a user’s data securely, without requiring the user to take the scary step of handing over an account password. Types of functionality provided by OAuth-enabled APIs include the following: • Getting access to a user’s social graph — their Facebook friends, people they’re following on Twitter, or their Google Contacts • Sharing information about a user’s activities on your site by posting to their Face- book wall or Twitter stream • Accessing a user’s Google Docs or Dropbox account to store data in their online filesystem of choice • Integrating business applications with one another to drive smarter decisions by mashing up multiple data sources such as a Salesforce CRM and TripIt travel plan Figure 1-1. Google’s AuthSub approval screen, asking users for permission for their Google Calendar 2 | Chapter 1: Introduction

📄 Page 15

In order to access or update private data via each of these APIs, an application needs to be delegated access by the owner of the data. Each of these APIs, and over 300 more around the Web (according to Programmable Web in February 2012), support OAuth for getting access. Having a common protocol for handling API authorization greatly improves the de- veloper experience because it lessens the learning curve required to integrate with a new API. At the same time, an authorization standard creates more confidence in the security of APIs because the standard has been vetted by a large community. Why Don’t These APIs Just Use Passwords for Authorization? Usernames and passwords are typically the lowest common denominator for authen- tication and authorization on the Web. They are used for HTTP Basic and HTTP Digest authentication and on countless login pages. However, asking a user for their password has a number of side effects: Trust A user may not trust providing their password to your application. Decreased user sensitivity to phishing Even if the user is comfortable providing their password to your application, mak- ing the user comfortable doing this around the Web can have negative long-term effects, such as making phishing scams more effective. Expanded access and risk When the user provides their password to your application, you get access to not only the data your application needs, but all other data in the user’s account. The application has an obligation to its users to securely store these passwords and prevent them from leaking. Many developers do not want the risk exposure of having this additional responsibility. Limited reliability When a user changes their password, your application no longer has access to their data. Revocation challenges The only way a user can revoke access to your application is by changing their password, which also revokes access to all other apps. Passwords become required When an API provider supports federated authentication mechanisms such as OpenID or SAML (see “Federated Authentication” on page 4), users may not have passwords on their accounts. This makes it impossible for those users to use applications powered by the API. Why Don’t These APIs Just Use Passwords for Authorization? | 3

📄 Page 16

Difficulty implementing stronger authentication If an API provider requires passwords for API authentication, it becomes challeng- ing to improve account security with technologies like CAPTCHAs or multifactor authentication (such as one-time password tokens). Terminology In order to understand OAuth, it’s important to first understand the relevant termi- nology. We’ll introduce some key terms up front, and then discuss additional terms throughout the book. Authentication Authentication is the process of verifying the identity of a user—knowing that the user is who they claim to be. In the real world, when a police officer asks for your identification, she’s verifying your identity by ensuring that the picture on your identification matches your likeness. On desktop computers and on the Web, authentication is about knowing that the user at the keyboard is the owner of the account. Authentication is typically performed by asking a user for a username and password. The username represents the user’s claimed identity, and the software application assumes that if the user provides the correct password that they are indeed that user. Federated Authentication Although many applications have their own system of accounts (including usernames and passwords), some applications rely on other services to verify the identity of users. This is called federated authentication. In a corporate IT environment, applications may trust an Active Directory server, a LDAP server, or a SAML provider to authenticate users. On the Web, applications often trust OpenID providers (such as Google or Yahoo!) to handle the authentication of users. There are many benefits to federation for both ap- plication developers and users. OpenID is the most common open web protocol for handling federated authentication. Although OpenID has been used on the Web for many years, we’ll discuss only OpenID Connect, which is the next-generation version of OpenID based on OAuth 2.0. Authorization Authorization is the process of verifying that a user has the right to perform some action, such as reading a document or accessing an email account. This typically first requires 4 | Chapter 1: Introduction

📄 Page 17

valid identification of the user (authentication) in order to check whether the actual user is authorized. When a police officer pulls over your car for speeding, she first authenticates you using your driver’s license (to verify your identity) and then checks the license (expiration date, restrictions, etc.) to ensure you’re authorized to drive. The same process happens online — a web application first verifies your identity by logging you in, and then it ensures that you access only the data and services you’re allowed to, typically by checking an access control list for each operation. Delegated Authorization Delegated authorization is granting access to another person or application to perform actions on your behalf. When you drive your car to a classy hotel, they may offer valet parking. You then authorize the valet attendant to drive your car by handing him the key in order to let him perform actions on your behalf. OAuth works similarly—a user grants access to an application to perform actions on the user’s behalf and the application can only perform the authorized actions. Roles There are several key actors in the OAuth protocol flows: Resource server The server hosting user-owned resources that are protected by OAuth. This is typ- ically an API provider that holds and protects data such as photos, videos, calen- dars, or contacts. Resource owner Typically the user of an application, the resource owner has the ability to grant access to their own data hosted on the resource server. Client An application making API requests to perform actions on protected resources on behalf of the resource owner and with its authorization. Authorization server The authorization server gets consent from the resource owner and issues access tokens to clients for accessing protected resources hosted by a resource server. Smaller API providers may use the same application and URL space for both the authorization server and resource server. Terminology | 5

📄 Page 18

The Great Debate over Signatures OAuth 1.0 required cryptographic signatures be sent with each API request to verify the identity and authorization of the client. Cryptography is challenging for the casual developer to grasp and also challenging for even highly skilled engineers to master. This led to plenty of developer frustration and, presumably, less adoption of APIs than could have been achieved with an easier authorization protocol. When OAuth 1.0 was developed in 2007, it was decided that cryptographic signatures were necessary to support the security of APIs. At the time, many top API providers hosted their APIs at vanilla HTTP endpoints, without SSL/TLS protection. Over the years, SSL/TLS became a more common way of protecting APIs and the need for sig- natures decreased in the eyes of some members of the security community. Combining the perception of low API adoption due to the complexity of cryptography in OAuth 1.0 and the greater prevalence of SSL/TLS support for APIs led to the devel- opment of the OAuth Web Resource Authorization Profiles (WRAP) specification. OAuth WRAP is the predecessor to OAuth 2.0—it eliminated the complex signature requirements and introduced the use of bearer tokens. Even as OAuth 2.0 nears finalization in the standards community, there remains some strong individual opposition to not requiring the use of signatures, including by Eran Hammer-Lahav, the editor of the specification. Eran has written a blog post titled OAuth 2.0 (without Signatures) Is Bad for the Web, in which he acknowledges the complexity of signatures for some developers but defends their value. He mainly points out that removing signatures from OAuth 2.0 makes it easy for developers to make mistakes and accidentally send their credentials to a malicious API endpoint, which can then abuse these credentials to make additional requests because they’re not pro- tected by a signature. While he argues that this isn’t likely today, he does believe it will become more critical as automated discovery is added for API and OAuth endpoints. Others identify cryptographic signatures as a feature that allows for greater confidence in the origin of API requests as the requests pass through multitiered architectures. Engineers often have to strike a delicate balance between security and usability, and this case is no different. Mitigating Concerns with Bearer Tokens One of the primary concerns with the elimination of signatures is that developers will not properly verify SSL/TLS certificate chains when making requests to the authoriza- tion and resource servers. This is required by the specification and addressed in the OAuth 2.0 threat model document, but the ease of disabling proper certificate and certificate authority validation in popular libraries, combined with the difficulty of fix- ing issues associated with it, has resulted in many developers taking shortcuts that threaten the security of their applications. 6 | Chapter 1: Introduction

📄 Page 19

When implementing OAuth 2.0, calling any APIs, or using a library, you should verify that it properly handles SSL/TLS certificate chain validation by doing the following things: • Checking that the hostname on the certificate returned by the server matches the hostname in the URL being accessed • Verifying each certificate in the chain properly chains up to a valid and trusted certificate authority (CA) • Ensuring that the certificate authority bundle on your server is secure and not able to be modified by potential attackers Signing Your OAuth 2.0 Requests The MAC Access Authentication specification defines how clients can sign their OAuth 2.0 requests when signatures are supported or required by the API provider. Author’s Note: If you’re thinking MAC only refers to a type of computer, you can un- derstand why signatures are hard for many developers! You might want to find a good book on cryptography. Getting the key In order to sign requests using MAC authentication, the client must first get a MAC key. This can be issued by the OAuth authorization server. In this case, the key is returned each time an access_token is returned by the authorization server. This MAC key must be for use in either the hmac-sha-1 or hmac-sha-256 algorithms. Alternatively, the MAC key can be issued in an out-of-band process, such as when the developer registers their application with the API provider. Regardless of how the key is issued, it must always be issued over a secure SSL/TLS channel and must be kept confidential. Making API requests When connecting to OAuth-enabled APIs that require signatures, each API request must include a MAC signature in the Authorization header of the request. The process of generating this signature involves creating a normalized request string (nonce, HTTP method, request URI, host, port, optional body hash, etc.) and performing a crypto- graphic signature. It is highly recommended that developers use a prebuilt library to handle OAuth MAC signing if needed. If you need to build your own implementation, please see the specification, as the details are out of scope for this book. Developer and Application Registration OAuth requires that applications register with the authorization server so that API requests are able to be properly identified. While the protocol allows for registration Developer and Application Registration | 7

📄 Page 20

using automated means, most API providers require manual registration via filling out a form on their developer websites. At the time of this writing • Google requires you to register your client by visiting its APIs Console, as shown in Figure 1-2. • Microsoft Windows Live requires you to register your client using its application management site. • Facebook requires you to register your client on the Facebook Developers site. Figure 1-2. Google’s APIs Console for OAuth app registration As an example, the following information is required to register an OAuth client with Google via their APIs Console: • Google Account • Product Name • Product Logo (optional) • Website URL used for Redirect URIs (for web applications only) After registration is complete, the developer is issued client credentials: Client ID Specified as client_id when interacting with the resource server Client Secret Specified as client_secret when exchanging an authorization code for an access token and refreshing access tokens using the server-side Web Application Flow (see Figure 7-1). 8 | Chapter 1: Introduction