The document provides an overview of OAuth, detailing its benefits for both API consumers and providers, and explaining the authentication process through various examples. It addresses the challenges of implementation and recommends that all web applications exposing APIs should support OAuth to enhance security and user experience. Additionally, it discusses version recommendations and common pitfalls for developers while emphasizing the importance of using established OAuth protocols.

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”
USER
Person using the service!
Where the service runs
Sometimes called “resource SERVER
owner” 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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

32. What
version
p
should
I
use?

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

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

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

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

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

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

40. Why
is
OAuth
so
Hard
for
p
Developers?

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

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

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

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

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

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

48. Next Time
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)

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