The document discusses user-centric identity and service invocation. It describes existing protocols like OpenID, SAML, and proprietary protocols from companies. It then introduces OAuth as an open standard for service invocation that is authentication method agnostic, easy for users and developers to implement, and provides security and privacy. OAuth defines a process for requesting user authorization for third-party access to protected services and resources in a standardized way.

1. ‘ User-Centric Identity’ based Service Invocation America Online LLC Praveen Alavilli XTech 2008 (Dublin)

2. Mashups, Gadgets, Widgets, Social Networks, Social Graphs, ….. no longer just about presenting content/feeds from multiple places the user and his/her friends it’s also about how users can use multiple services together the global mapping of everybody and how they are related Opening up a lot of questions about Data Portability .

3. Service Invocation Actions that a client/user-agent performs to use a Web Service / API Several definitions when it’s related to a user ‘ Deputization’ of services ‘ Delegation’ of actions (act on behalf of a user)

4. Identity still at the ‘core’ So the users can control the flow of their data/information authorize access to their information personalize applications/data communicate publish content online Call it User-Centric or User-Centered :-)

5. User-Centric Identity Open, Community driven and standards based OpenID No support for Service Invocation InfoCard (CardSpace) No direct support for Service Invocation (although you can define a security token as another claim) SAML Liberty ID-WSF WS-* Too heavy for browser based apps and designed mainly for XML based Web Services (SOAP) Complex message formats and protocols for developers and browser based apps

6. Proprietary Protocols AOL OpenAuth Yahoo! BBAuth Google Account Auth API (AuthSub) Windows Live ID All support service invocation with user’s consent (authorization) across all their Open Services but …. Different ways to obtain user consent/permission Different user experience Different protocols, message formats and parameter names Each defines it’s own: URL format, Parameters naming convention, Response specification, and Status Codes Lack of consistent model for rich clients (like Flash/Flex Apps, desktop clients) and browser based apps

7. AOL Open Services http://dev.aol.com

8. AOL OpenAuth and Open Services Untrusted Site (ex. netvibes.com) User (Browser) 1. Access protected content 2. Redirect to OpenAuth 3. login 4. Login page 5. sn/pwd 6. Redirect to site w/ token 7. Redirect to site w/ token 8. Get buddylist W/ token 9. Validate token 10. Return buddy list AIM Service 11. Return Personalized content

9. AOL OpenAuth and Open Services

10. AOL OpenAuth and Open Services

11. Yahoo! Open APIs/Services http://developer.yahoo.com

12. Yahoo! BBAuth

13. Yahoo! BBAuth

14. Yahoo! BBAuth

15. Google Open APIs/Services (GData) http://code. google .com/more/

16. Google AuthSub

17. Google AuthSub

18. And the list goes on… Source: http://programmableweb.com/apis

19. What do we need ? A open standard for Service Invocation that’s authentication method agnostic easy for users to understand provide Security and Privacy where ever appropriate consistent and easy to implement for developers open source code libraries open and community driven specification

20. OAuth (Oh! Auth) An Open protocol to allow Secure API Authentication in a simple and standard method from desktop and web applications.

21. What it’s Not ? User Authentication Protocol Token specification Web/Client SSO Protocol Part of OpenID spec nor an extension Consumer Key (developer key) and Secret provisioning protocol

22. What it really provides ? A simple and easy way to request user’s authorization , and a consistent way to access services on behalf of the user (service invocation). Analogous to AOL/Yahoo/Google/…. Open Service protocols but Authentication is left out of scope intentionally !

23. OAuth protocol Defines 3 request URLs: Request Token URL to obtain unauthorized token User Authorization URL to obtain user authorization for consumer access Access Token URL to exchange user-authorized token with an access token + an easy to extend framework (guidelines) to suit your needs

24. OAuth Parameters oauth_consumer_key oauth_consumer_secret oauth_token oauth_token_secret oauth_signature oauth_signature_method oauth_timestamp oauth_nonce oauth_version oauth_callback **Service Providers can add additional request parameters as per their needs but they MUST NOT begin with “oauth_” **

25. Where are they passed ? URL Query Parameters HTTP POST request body (as form params) HTTP Authorization Header (most preferred way)

26. Request Signing All token requests and protected resources requests MUST be signed to prevent token misuse. OAuth does not mandate a particular signature method (HMAC-SHA1, RSA-SHA1, etc.) but it does define how you construct Signature Base String. Signature Base String = HTTP Request Method + ‘&’ + request URL + ‘&’ + Normalized Request Parameters Signing Key = oauth_consumer_secret + “&” + oauth_token_secret

27. Various use-cases still being worked on ! Auto discovery of OAuth end points and auto-provisioning User - Gadget - Container - Service Provider interactions (for Gadget/Widget containers like Netvibes, iGoogle, etc.) Consumer using a Service Provider that provides multiple resources Consumer using Multiple Service Providers using same IDP Consumer using a Service Provider outsourcing Identity to some one other IDP using OpenID/InfoCard/etc. Consumer - Service Provider Transactions with no User (two-legged scenario) Security related - session extension, additional/expired authorizations, token revocation, etc.. Out of band Authorization

28. Extensions in draft mode Error Reporting Extension RSA Key Rotation Extension Gadgets Extension Session Extension Language Preference Extension Consumer Request Extension for two-legged scenarios Multi-Resource Authorization Extension

29. OAuth Discovery Extension Provides a way for discovering the Service Providers using a XRDS Document to indicate where it’s end points are, and how to obtain required configuration data

30. Sample XRDS Document <!-- Request Token --> <Service> <Type>http://oauth.net/core/1.0/endpoint/request</Type> <Type>http://oauth.net/core/1.0/parameters/auth-header</Type> <Type>http://oauth.net/core/1.0/parameters/post-body</Type> <Type>http://oauth.net/core/1.0/parameters/uri-query</Type> <Type>http://oauth.net/core/1.0/signature/HMAC-SHA1</Type> <URI>https://api.screenname.aol.com/auth/oauth_request_token</URI> </Service> <!-- User Authorization --> … . <!-- Access Token --> … . <!-- Protected Resources --> <Service> <Type>http://oauth.net/core/1.0/endpoint/resource</Type> <Type>http://oauth.net/core/1.0/parameters/auth-header</Type> <Type>http://oauth.net/core/1.0/parameters/post-body</Type> <Type>http://oauth.net/core/1.0/parameters/uri-query</Type> <Type>http://oauth.net/core/1.0/signature/HMAC-SHA1</Type> </Service> <!-- Consumer Identity --> <!-- Manual Consumer Identity Allocation --> <Service> <Type>http://oauth.net/discovery/1.0/consumer-identity/oob</Type> <URI>https://dev.aol.com/keys</URI> </Service>

31. How does OAuth fit in your existing deployments ?

32. Deployment Models SP has Central IDP OAuth endpoints handled by IDP OAuth endpoints handled by SP SP is IDP Oauth endpoints handled by SP SP with no IDP Using OpenID or InfoCard or any other Protocol

33. Central IDP Model - 1 OAuth endpoints handled by IDP. SP OAuth Discovery Document returns endpoints as IDP Urls.

34. Central IDP Model - 2 OAuth endpoints handled by SP Example: A simple OAuth Proxy Sevlet that routes all requests to IDP internally.

35. SP is IDP OAuth endpoints handled by SP

36. SP with no IDP OAuth endpoints handled by SP but Authentication handled by OpenID (or InfoCard, or any other mechanism)

37. Supporting OAuth in existing Services Sample WebAIM call: (http://dev.aol.com/webaim/) http://api.oscar.aol.com/aim/startSession? f=xml&events=myinfo,presence,buddylist & a =<token>& k = co1dDRMvlgZJXvWK OAuth enabled: http://api.oscar.aol.com/aim/startSession?oauth_consumer_key=co1dDRMvlgZJXvWK&oauth_token=<token>&oauth_signature_method=HMAC-SHA1&oauth_signature=<signature>&oauth_nonce=<nonce>&oauth_timestamp=1191232096&f=xml&events=myinfo,presence,buddylist (OR) http://api.oscar.aol.com/aim/startSession?f=xml&events=myinfo,presence,buddylist HTTP Header: Authorization: OAuth realm=&quot;http://api.oscar.aol.com/&quot;, oauth_consumer_key=&quot; co1dDRMvlgZJXvWK &quot;, oauth_token=“<token>&quot;, oauth_signature_method=&quot;HMAC-SHA1&quot;, oauth_signature=”<signature>&quot;, oauth_timestamp=&quot; 1191232096 &quot;, oauth_nonce=”<nonce>&quot;, oauth_version=&quot;1.0&quot;

38. If you are still wondering ‘why is it useful ?’ … For End users Security All requests are signed Nonce & timestamp for stopping replay attacks User login credentials are not exposed Tokens can be revoked (if supported by IDP) to stop a malicious Consumer from having continuous access to protected resources Privacy Consumer authorization under user’s control User information not shared with Consumers User Experience Consistent Login experience Easy to understand authorization process Control on information/data access

39. For Developers and Service Providers Developers Consistent APIs across different Service Providers for passing Identity Information No need to worry about managing Identities and Authentication Platform/OS independent Simple Protocol and Message format Service Providers Easy way to increase adoption of their Services Provides security and privacy of their users One Consistent and Simple API to maintain for both Rich Clients and Browser Based Apps.

40. Questions/Comments Reference Sites: OAuth: http://oauth.net OAuth Group: http://groups. google .com/group/ oauth OAuth Extensions: http://groups.google.com/group/oauth-extensions OAuth Code: http:// oauth .net/code/ AOL OpenAuth: http://dev.aol.com/openauth Contact Info: Praveen Alavilli AlavilliPraveen @aol.com http://dev.aol.com/blog/82