1.
OAuth: The Big Picture 8.11.11 @ 11:05 PST VOIP or Dial-­‐in (see chat) Greg Brail @gbrail Brian Pagano @brianpagano

2.
@gbrail @brianpagano

3.
API Workshop Webinar Series (videos & slides at http://blog.apigee.com/taglist/webinar)Mapping out your API Strategy PragmaHc REST: API Design Fu 10 PaLerns in Successful API Programs What to Measure: API AnalyHcs Is your API Naked? API Tech & OperaHons Does your API need PCI? (Compliance) Developers Hate MarkeHng: Driving API AdopHon OAuth: The Big Picture “Boss, we need an API” (coming Sep 14)

4.
Topics A Brief IntroducHon to OAuth Why OAuth is good for API consumers (really!) Why OAuth is good for API providers ImplementaHon challenges for the provider RecommendaHons

5.
A Brief IntroducHon to OAuth

6.
Mo;va;ons Behind OAuth We all understand the idea of a service APIs, web sites that support mobile apps … We all understand password-­‐based security: Provide your creden:als in a secure way to gain access

7.
Mo;va;ons Behind OAuth Services are used by applica;ons Your web browser is merely one applica:on Services and passwords don’t mix well How many applica:ons have your password? Do you trust them all? Are you sure?

8.
What is OAuth? OAuth is another way to authenHcate to a service. .

9.
Imagine .... …you had a different password for every service Already do? You are in a :ny minority. …you had a different password for every applicaHon A compromised applica:on can’t wreak as much havoc …You can’t possibly remember it or write it down Instead, it is stored by the applica:on that needs it

10.
That’s what OAuth does.

11.
See Eran Hammer-Lehav’s writeup on the history of OAuth: http://hueniverse.com/oauth/guide/history/

12.
Terminology (simplified) App used to access service CLIENT Sometimes called “consumer” USERPerson using the service! Where the service runsSometimes called “resource SERVERowner” Sometimes called “service provider”

13.
Example OAuth Flow 1. Bob visits bit.ly, which uses a service provided by TwiLer. Bob already has logins for bit.ly and TwiLer. 2. Behind the scenes, bit.ly uses its OAuth credenHals to begin the authenHcaHon process for Bob 3. bit.ly redirects Bob temporarily to twiLer.com to log in. bit.ly never sees Bob’s TwiIer password 4. If and only if this is successful, bit.ly uses its own OAuth creden;als to retrieve credenHals for Bob 5. bit.ly stores Bob’s new credenHals along with Bob’s account. They allow him to use bit.ly, and only bit.ly, to access TwiLer

14.
Let’s see that again Bob’s bit.ly password BIT.LY (CLIENT) Bob’s OAuth credentials for Twitter API a BOB cc (USER) ess Bob’s Twitter TWITTER password (SERVER)

15.
What if... bit.ly is hacked and the password database is leaked? TwiDer revokes bit.ly’s OAuth creden:als All creden:als stored by bit.ly are immediately rejected TwiLer users don’t have to change their passwords

16.
What if... Hackers phish Bob and get his TwiLer password? He changes his TwiDer password as soon as he knows. Bob doesn’t have to do anything at bit.ly because it never had the password

17.
Next Example: OAuth Flow for Mobile Apps 1. Bob launches FooApp, which uses a service provided by TwiLer. 2. Bob already has a TwiLer username and password. 3. Behind the scenes, FooApp uses its OAuth credenHals to begin the authenHcaHon process for Bob 4. FooApp opens a browser window and directs Bob to TwiLer to log in. FooApp never sees Bob’s TwiLer password 5. If and only if this is successful, FooApp uses its OAuth credenHals to retrieve credenHals for Bob 6. FooApp stores these locally. They allow Bob to use FooApp, and only FooApp to access TwiLer

18.
Another Example OAuth Flow Bob’s OAuth token for Twitter FOOAPP (CLIENT) API a BOB cc (USER) ess Bob’s Twitter TWITTER (SERVER) password

19.
What if... Bob loses his phone, and he didn’t set a phone password? He immediately logs in to TwiDer He revokes the creden:als that TwiDer gave FooApp on his phone He doesn’t have to change his TwiLer password because his phone never had it.

20.
For Web Apps that Expose APIs OAuth means that web apps don’t have to share passwords

21.
For Web Apps that Expose APIs The alternaHve to OAuth is an unacceptable security risk for modern web apps. The other alternaHve is some sort of universal single-­‐sign-­‐on mechanism.

22.
Recommenda;on We believe that all web applica:ons that expose APIs to other web applica:ons must support OAuth.

23.
For APIs Designed for Mobile and Na;ve Apps: OAuth eliminates the need to store a password on a mobile device. An OAuth token.. ..is harder to guess ..is :ed to a par:cular applica:on and device ..may be revoked without affec:ng other devices and apps

24.
For APIs Designed for Mobile and Na;ve Apps OAuth makes the authenHcaHon process future-­‐proof It’s under the control of the API team SSL, mul:-­‐factor authen:ca:on, terms of service, you name it – there is a place to plug it in without touching the client

25.
Recommenda;on We believe that all APIs that support mobile and na:ve apps should support OAuth … ..and encourage or require it for mobile and na:ve apps

26.
For Server-­‐to-­‐Server APIs Having a separate set of authenHcaHon credenHals for each applicaHon is a nice feature of OAuth… But for server-­‐to-­‐server use, the need to log in securely using a browser gets in the way Simply assigning a unique password to each applicaHon is sufficient (or two-­‐way SSL is another good but cumbersome approach)

27.
Recommenda;on We believe that OAuth is not necessary for APIs that are only used by other servers… …but once those APIs are useful for other types of clients – and they usually do – then you are back in the OAuth game!

28.
But I Hate OAuth! p Picture by g-mikee

29.
OAuth is more cumbersome for developers than plain passwords.

30.
But OAuth is a lot beLer for the end user. No password sharing between web apps No passwords stored on mobile devices Using OAuth is worth the effort.

31.
What version p should I use?

32.
What Version of OAuth Should I Use? 1.0 Had a security flaw. No one should be using it now! Stable and well-­‐understood. 1.0a Uses a signature to exchange credenHals between client and server. So…SSL is not necessary, but geing the signature right is tricky. AcHvely under development in the IETF 2.0 Slowly but surely geing stable – core flows unlikely to change much Supports a “bearer token,” which is easier to code but requires SSL OpHonal specs to support signatures, SAML, etc. but specs not yet stable

33.
“Fl-­‐OAuth Chart” for the API Team Use OAuth 2.0 with bearer tokens Can your API require HTTPS? Use OAuth 1.0a

34.
How Should I Use OAuth 2.0? Just a big random number BEARER TOKEN Requires SSL By far the simplest to implement – USE IT! Like OAuth 1.0a, uses signature instead of SSL MAC TOKEN SHll changing -­‐ WAIT! Makes sense if the API team and developers SAML really want SAML But sHll changing -­‐ WAIT!

35.
How Should I Use OAuth 2.0? Different ways to get the token: “Authoriza:on Code” – designed for use by web apps <-­‐ important! “Implicit Grant” – designed for JavaScript-­‐rich web apps <-­‐ also important! “Resource Owner Password Creden:als” “Client Creden:als” Bypass many parts of the OAuth flow Re-­‐introduces password sharing Basically ways to make “OAuth” work when you don’t really want OAuth

36.
What Version of OAuth 2.0 Should I Use? I’m not sure why this is even a quesHon. You should use the latest one.

37.
What are Legs and How Many Does OAuth Have? Since there is a user, a client, and a server in OAuth, some 3-LEGGED people call it “three-­‐legged OAuth” Some APIs idenHfy just the “client” and not the “user” 2-LEGGED Omen this is done using SSL But an OAuth 1.0 signature may be used instead Technically, “two-­‐legged OAuth” is not OAuth at all

38.
Why is OAuth so Hard for p Developers?

39.
Why is OAuth so Hard for Developers? The “authenHcaHon dance” is painful. Signatures are painful. They are now op:onal (and up to the discre:on of the provider) in 2.0 There are a lot of libraries – use them Ge]ng the signature algorithm right is harder than it looks at first!

40.
Why is OAuth so Hard for Developers? Where do you store the credenHals on the client? They must be available in clear text Mobile devices can break them into pieces .. but in the end :me and physical access will eventually wear down anything At any rate storing the original password directly is worse!

41.
When OAuth is a Bad Idea Anything that is not done on behalf of a human Admin tools, server-­‐to-­‐server communica:on, … Anything that requires “commercial” levels of trust If you require the capabili:es of a PKI then OAuth is not that One-­‐;me tokens OAuth is a lot of machinery to make one API call

42.
Other Bad Ideas “We have our own version of OAuth”

43.
Other Bad Ideas “We invented something that’s kind of like Oauth”

44.
More Recommenda;ons DEVELOPERS Use a library Think about using a proxy Use OAuth 2.0 Use Bearer Tokens Use “AuthorizaHon code” and “implicit grant” only API TEAM Use the latest dram! Default to SSL Think about using a product At least use a library for signatures

45.
Next TimeMapping out your API Strategy PragmaHc REST: API Design Fu 10 PaLerns in Successful API Programs What to Measure: API AnalyHcs Is your API Naked? API Tech & OperaHons Does your API need PCI? (Compliance) Developers Hate MarkeHng: Driving API AdopHon OAuth: The Big Picture “Boss, we need an API” (Sep 14)

46.
THANK YOU Ques:ons and ideas to:@gbrail @brianpagano