oauth for your api - the big picture
DESCRIPTION
OAuth is taking off as a standard way for apps and websites to handle authentication. But OAuth is a fast moving spec that can be hard to pin down. Why should you use OAuth and what are the business and operational benefits? What's the story with all of the different versions and which one should you choose? Watch this webinar with Apigee's CTO Gregory Brail and Sr. Architect Brian Pagano for 'big picture straight talk' on these OAuth questions and more.TRANSCRIPT
OAuth: The Big Picture
8.11.11 @ 11:05 PST VOIP or Dial-‐in (see chat)
Greg Brail @gbrail
Brian Pagano @brianpagano
@brianpagano @gbrail
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)
API Workshop Webinar Series (videos & slides at http://blog.apigee.com/taglist/webinar)
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
Topics
A Brief IntroducHon to 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
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?
Mo;va;ons Behind OAuth
OAuth is another way to authenHcate to a service. .
What is OAuth?
…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
Imagine ....
That’s what OAuth does.
See Eran Hammer-Lehav’s writeup on the history of OAuth: http://hueniverse.com/oauth/guide/history/
Terminology (simplified)
USER
SERVER
CLIENT
Person using the service! Sometimes called “resource owner”
App used to access service Sometimes called “consumer”
Where the service runs Sometimes called “service provider”
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
Example OAuth Flow
Let’s see that again
BOB (USER)
TWITTER (SERVER)
BIT.LY (CLIENT)
Bob’s bit.ly password Bob’s OAuth credentials for Twitter
Bob’s Twitter password
API a
cc
ess
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
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
What if...
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
Next Example: OAuth Flow for Mobile Apps
Another Example OAuth Flow
BOB (USER)
TWITTER (SERVER)
FOOAPP (CLIENT)
Bob’s OAuth token for Twitter
Bob’s Twitter password
API a
cc
ess
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.
What if...
OAuth means that web apps don’t have to share passwords
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.
For Web Apps that Expose APIs
We believe that all web applica:ons that expose APIs to other web applica:ons must support OAuth.
Recommenda;on
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
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
For APIs Designed for Mobile and Na;ve Apps
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
Recommenda;on
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)
For Server-‐to-‐Server APIs
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!
Recommenda;on
p But I Hate OAuth!
Picture by g-mikee
OAuth is more cumbersome for developers than plain passwords.
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.
p What version should I use?
Had a security flaw. No one should be using it now! Stable and well-‐understood. 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 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
What Version of OAuth Should I Use?
1.0
1.0a
2.0
“Fl-‐OAuth Chart” for the API Team
Can your API require HTTPS?
Use OAuth 2.0 with bearer tokens
Use OAuth 1.0a
How Should I Use OAuth 2.0?
BEARER TOKEN
MAC TOKEN
SAML
Just a big random number Requires SSL By far the simplest to implement – USE IT! Like OAuth 1.0a, uses signature instead of SSL SHll changing -‐ WAIT! Makes sense if the API team and developers really want SAML But sHll changing -‐ WAIT!
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
How Should I Use OAuth 2.0?
I’m not sure why this is even a quesHon. You should use the latest one.
What Version of OAuth 2.0 Should I Use?
Since there is a user, a client, and a server in OAuth, some people call it “three-‐legged OAuth”
Some APIs idenHfy just the “client” and not the “user” 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
What are Legs and How Many Does OAuth Have?
3-LEGGED
2-LEGGED
p 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!
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!
Why is OAuth so Hard for Developers?
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
When OAuth is a Bad Idea
“We have our own version of OAuth”
Other Bad Ideas
“We invented something that’s kind of like Oauth”
Other Bad Ideas
Use a library Think about using a proxy
Use OAuth 2.0 Use Bearer Tokens Use “AuthorizaHon code” and “implicit grant” only Use the latest dram! Default to SSL Think about using a product At least use a library for signatures
More Recommenda;ons
DEVELOPERS
API TEAM
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” (Sep 14)
Next Time
THANK YOU Ques:ons and ideas to: @gbrail @brianpagano