Tài liệu Getting Started with OAuth 2.0 ppt

LINK DOWNLOAD MIỄN PHÍ TÀI LIỆU "Tài liệu Getting Started with OAuth 2.0 ppt": http://123doc.vn/document/1047617-tai-lieu-getting-started-with-oauth-2-0-ppt.htm

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
www.it-ebooks.info
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
www.it-ebooks.info
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
www.it-ebooks.info
www.it-ebooks.info
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
www.it-ebooks.info
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
www.it-ebooks.info
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
www.it-ebooks.info
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
www.it-ebooks.info
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
www.it-ebooks.info
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
www.it-ebooks.info