OAuth & OpenID for Data Access and Identity in Web Apps Ryan Boyd http://profiles.google.com/ryan.boyd @ryguyrg
Agenda 1
Concepts & Terminology
2
Authorization with OAuth 2.0
3
Authentication with OpenID Connect
4
User Experience
5
Google Identity Toolkit
6
Resources, Q&A
Concepts & Terminology
Authentication
Authorization
Delegation
Authentication & Authorization on the Web
Quick Poll
Do you use the same username & password for multiple web sites? Yes!
Quick Poll
How many keystrokes do you type to sign up for a new account? 50+!
Quick Poll
Have you ever shared a password so another app can access your data? Yes!
Challenges How can we: 1) minimize the number of accounts and passwords users need to remember? 2) discourage password reuse? 3) optimize sign-up flows to onboard users faster?
OpenID Connect
Challenges How can we: 1) eliminate the need to reveal passwords to share data with 3rd-party applications? 2) restrict the level of data available to 3rd-party applications?
OAuth 2.0
OAuth 2.0
35+ APIs
Example OAuth-enabled APIs
Contacts
Calendar
Picasa Web Albums
YouTube
Demo https://tasks-sample-app.appspot.com/
OAuth 2.0 - What’s new? ✓ Defined flows for different environments ✓ Improved user & developer experience ✓ Short lived, refreshable bearer tokens ✓ Avoids complex cryptography ✓ Leverages SSL/HTTPS
Tokens & Codes Access Token - Short lived credential for accessing protected resources. Authorization Code - Intermediate token representing an authorization grant, redeemable for access & refresh tokens Refresh token - Long lived token, redeemable for access tokens
SaaSy Payroll
SaaSy Payroll
SaaSy Payroll
OAuth 2.0: Roles Client o Web application o Needs access to the protected resource
Resource Server o Holds the protected resource
Protected Resource o Resides on server o Requires authorization
Authorization Server o Issues Access Tokens
Resource Owner o Owns protected resource o Approves access
Client Registration Developer registers application with resource/authorization server, gets a client_id and client_secret
OAuth 2.0 - Flows
Flows supported by Google • Implicit flow for Client-side Web Applications • Authorization code flow for Server-side Web Applications • Device flow for apps on devices with limited input
OAuth 2.0 - User Agent Flow (Implicit Grant)
When to use • Apps residing on client device - web mashups, mobile, desktop apps where embedding client keys & secrets is not secure • When you only require temporary or one-time access to the protected resource
Requesting Authorization 1
Application redirects user to Google, specifying: client_id obtained during registration redirect_uri for user to return to scope or APIs the app needs access to. response_type value of token requests an implicit grant.
Obtaining Access Tokens 2
Google redirects the user back to the application’s redirect_uri and includes an access_token in the URL fragment ID. http://www.saasyapp.com/payroll/ back#access_token=&token_type=bearer&expire s_in=3600
3
Application extracts access token from URL fragment ID (JavaScript). var data = {}; window.location.hash.replace( new RegExp("([^#=&]+)(=([^&]*))?", "g"), function($0, $1, $2, $3) { data[decodeURI($1)] = decodeURI($3); }); access_token = data["access_token"];
X
Calling an OAuth 2.0 Protected API 4
Application makes a HTTP GET or HTTP POST request to the server containing the protected resource, including the access_token as a query param or header. Query-param (e.g. JSON-P with
Server Integration /** * Returns the account info for an email, or null if not registered. * The email and accountType fields must be set in returned Account */ Account getAccountByEmail(String email) { // To be implemented by RP. } /** * Returns whether the password is valid for the user. */ boolean checkPassword(String email, String password) { // To be implemented by RP. } /** * Upgrade a legacy email account to federated login. * The response code may be OK, ACCOUNT_NOT_FOUND, * ACTION_NOT_ALLOWED, UNKNOWN_ERROR. */ ResponseCode toFederated(String email){ // To be implemented by RP. Normally just update the user-account DB }
GITKit Benefits ✓ Pre-built Account Chooser UI ✓ Same infrastructure Google uses ✓ Hides most of the complexity around adopting federated identity ✓ Supports legacy users, upgrade to federated login ✓ Libraries available for Java, PHP
Mobile Use Cases
Authentication 1
2
Embed a web browser & use OpenID: Android: WebView iOS: UIWebView Issue a proprietary token to your app: Similar to a session token
3
Extract the token: Android: CookieManager iOS: NSHttpCookieManager All: window title
4
Call your APIs, passing the token
Authorization 1
2
3
Embed a web browser & use OAuth: Android: WebView iOS: UIWebView Get an OAuth 2.0 access_token for your app, using either the implicit flow or native app flow: Implicit: use JavaScript hosted by your web server Native: specify redirect_uri of urn:ietf:wg:oauth:2.0:oob
Call Google’s APIs, passing the access_token
Authorization - Android & Tasks 1
2
3
Use the GoogleAccountManager and request a token of type Manage Your Tasks After the user approves access, your app will get an OAuth 2.0 access_token
Call Google’s APIs, passing the access_token
Summary
Summary • Developers have an obligation to help users stay safe, use good password practices • Leveraging standards like OAuth 2.0 and OpenID Connect helps • OAuth 2.0 for securely accessing user data – Industry standard nearing finalization – Well defined flows for different use cases – Simplified protocol, avoids many of the pitfalls in previous attempts • OpenID Connect for federated login – Builds on OAuth 2.0 – Account Chooser or GITKit for great UX!
Resources, Q&A and Feedback Google’s AuthNZ docs - http://code.google.com/apis/accounts/ OAuth 2.0 - http://oauth.net/2/ OAuth 2.0 playground - https://code.google.com/oauthplayground/ Google Identity Toolkit - http://code.google.com/apis/identitytoolkit/ Account Chooser - http://accountchooser.com OpenID Connect - http://openid.net/connect/
@ryguyrg
http://profiles.google.com/ ryan.boyd
