This is the first presentation on the series "Introduction to OAuth 2.0". OAuth 2.0 solves the pressing security problem of avoiding password anti-pattern when allowing delegated authorization.

1. @nabeelxy
10/26/2014

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