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.
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
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
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.