UserCentric Identity based Service Invocation
- 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="http://api.oscar.aol.com/", oauth_consumer_key=" co1dDRMvlgZJXvWK ", oauth_token=“<token>", oauth_signature_method="HMAC-SHA1", oauth_signature=”<signature>", oauth_timestamp=" 1191232096 ", oauth_nonce=”<nonce>", oauth_version="1.0"
- 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
Editor's Notes
- #2: With the growing acceptance of OpenID across the web as a simple and easy way to exchange Online Identities, now is the time to look at how the new protocol OAuth helps in doing Identity based Service Invocations to help in building useful Web 2.0 applications (including Widgets and Gadgets for Social Networks) all under user’s control. This session introduces the OAuth protocol and how it can be used in various use cases. While doing so we will cover how it fits into the existing deployments with OpenID and possibly, other Authentication protocols as well. We will also discuss how OAuth fits into the two most common models where both User Identity and Services are managed by the same Provider or by different Providers. This of course opens up lot of questions about how OAuth and OpenID would work with each other and how the user’s permissions are managed. We will also look at how easy it is to add OAuth support into an existing Service using AOL’s WebAIM Service as an example.