24
@nabeelxy 10/26/2014

Introduction to OAuth 2.0 - Part 1

Embed Size (px)

Citation preview

Page 1: Introduction to OAuth 2.0 - Part 1

@nabeelxy

10/26/2014

Page 2: Introduction to OAuth 2.0 - Part 1

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

Page 3: Introduction to OAuth 2.0 - Part 1

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!

Page 4: Introduction to OAuth 2.0 - Part 1

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

Page 5: Introduction to OAuth 2.0 - Part 1

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.

Page 6: Introduction to OAuth 2.0 - Part 1

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?

Page 7: Introduction to OAuth 2.0 - Part 1

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.

Page 8: Introduction to OAuth 2.0 - Part 1

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

Page 9: Introduction to OAuth 2.0 - Part 1

OAuth sounds great. Sam, could you give us some details of it?

Tom, Twitter App Manager Sam, App Dev

Sure.

Page 10: Introduction to OAuth 2.0 - Part 1

Password Anti-Pattern Give resource owner’s (Bob’s) username and password to

client (Twitter App) in order to access the resource server (FB account) 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

Page 11: Introduction to OAuth 2.0 - Part 1

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

Page 12: Introduction to OAuth 2.0 - Part 1

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

Page 13: Introduction to OAuth 2.0 - Part 1

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

Page 14: Introduction to OAuth 2.0 - Part 1

Tweet

Bob Twitter App

Automatically post in Bob’s FB wall

CLIENT

RESOURCE SERVER

RESOURCE OWNER

AUTHORIZATION SERVER

Page 15: Introduction to OAuth 2.0 - Part 1
Page 16: Introduction to OAuth 2.0 - Part 1
Page 17: Introduction to OAuth 2.0 - Part 1
Page 18: Introduction to OAuth 2.0 - Part 1
Page 19: Introduction to OAuth 2.0 - Part 1
Page 20: Introduction to OAuth 2.0 - Part 1

Server-side web application

Client side web application running in the web browser

Native application

Page 21: Introduction to OAuth 2.0 - Part 1

Most OAuth 2.0 APIs uses bearer tokens to let clients make authorized requests

Access Token lets a client access a protected resource

How to send your access token with an API request? Preferred method is to use HTTP Authorization header GET /tasks/v1/lists/@default/tasks HTTP/1.1

Host: www.googleapis.com

Authorization: Bearer ya29.AHES6ZSzX

Page 22: Introduction to OAuth 2.0 - Part 1

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)

Page 23: Introduction to OAuth 2.0 - Part 1

Implementing authorization code flow for service

Authorization flow diagrams

Page 24: Introduction to OAuth 2.0 - Part 1

OAuth 2.0 Authorization Framework (RFC 6749)

Getting Started with OAuth 2.0