Introduction to OAuth 2.0 - Part 1
- 2. Wouldn’t it be cool when I tweet, it automatically gets posted in my FB wall? Tweet Bob Twitter App Automatically post in Bob’s FB wall
- 3. How does the Twitter App writes in Bob’s FB wall? I mean how does it get write access to Bob’s FB wall? Tom, Twitter App Manager Jim, Twitter App Dev Let’s store Bob’s FB username and password in his Twitter App account. Then the app can login and post in his FB wall. The problem solved!
- 4. It works. But it is not a good idea to store username and password as it involves a lot of risks. Besides, Bob won’t like to give his username/password to our app considering the fact that it take a while for users to trust our app. Jill, App Dev I totally agree. This is actually called Password Anti-Pattern! At all cost, we should avoid it. Sam, App Dev
- 5. We get more access than we want with username/password as well. Users will not like it. Further, this is bad from the point of view of liability when things go wrong. Sam, App Dev Further, if users change their FB password, it breaks our app. If users want to stop cross posting in FB, they will always have to come to our app or change their FB password.
- 6. Alright, asking for username and password is not good for Bob as well as us. So, what can we do about it? Tom, Twitter App Manager Basically the problem is that we need a way for our users to give us write authorization to their FB walls?
- 7. Ali, App Dev I was thinking that this problem is strikingly similar to the valet parking situation. I want to get my new car valet parked but I am at the same time hesitant to give my car key to them. The car industry came with this idea of valet keys that has limited capabilities. For example, that valet key allows to drive a car only a short distance and most of the add-on functions in the car are disabled for that special key. So, now I can give my valet key (instead of the original key) to valet park without worrying too much about it.
- 8. So, this sounds like a valet key would map to a short-lived token just like those in Kerberos protocol, even though Kerberos is for authentication? Jim, Twitter App Dev Yes, indeed. There is in fact a token based delegated authorization mechanism called OAuth. Good news is that FB is actually supporting OAuth for such access. Sam, App Dev
- 9. OAuth sounds great. Sam, could you give us some details of it? Tom, Twitter App Manager Sam, App Dev Sure.
- 10. Password Anti-Pattern Give resource owner’s username and password to client in order to access the resource server on behalf of the resource owner Dangers of using this pattern Expanded access and risk (exposure of username/password to third-party client) Limited reliability when passwords are changed Revocation challenges First Solutions Google’s AuthSub Yahoo’s BBAuth
- 11. A delegated authorization protocol 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 Introduced in 2007 Increased developer experience and increased confidence in security due to a common protocol for handling API authorization
- 12. Not backward compatible with OAuth 1.0 New flows Signatures are replaced by HTTPS (bearer tokens) Simplified signatures Short-lived tokens Separation of roles for authorization server and resource server
- 13. Resource server The server that hosts user owned resources protected by OAuth An API provider such as Google, Facebook, etc. Resource owner An application user Has the ability to grant access to their own data hosted on a resource server Client An application making API calls to perform certain action on protected resources on behalf of the resource owner with resource owner’s authorization Authentication server Often, it is same as the resource server
- 14. Tweet Bob Twitter App Automatically post in Bob’s FB wall CLIENT RESOURCE SERVER RESOURCE OWNER AUTHORIZATION SERVER
- 15. Server-side web application Client side web application running in the web browser Native application
- 16. Authorization code For apps with backend servers Implicit grant for browser based client side applications (no backend server) Resource owner password based grants Only for very trusted applications (usually for first-party applications only) Client credentials For application access (i.e. client is an application)
- 17. Authorization flow sequence diagrams Implementing authorization code flow OAuth for mobile applications
- 18. Getting Started with OAuth 2.0
Editor's Notes
- #13: http://hueniverse.com/2010/05/15/introducing-oauth-2-0/ 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 signatures decreased in the eyes of some members of the security community. In Oauth 2.0 - transition: Signature HTTPS 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 development 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.