1. OAuth
–
authen+ca+on
&
authoriza+on
framework
for
REST
APIs
Paul
Madsen
Ping
Iden+ty

4. Authen+ca+on
for
SOAP
• The
SOAP
world
has
long
had
standards
related
to
authen+ca+on
&
authoriza+on
of
web
services
• WS-­‐Trust
defines
a
protocol
by
which
a
SOAP
client
can
obtain
a
security
token(typically
a
SAML
asser+on)
• WS-­‐Security
s+pulates
how
to
aKach
the
token
(SAML
asser+on)
to
a
SOAP
request

5. But
…..

6. 1)
REST
authen+ca+on
• REST
world
has
not
had
comparable
standards
• Nothing
comparable
to
WS-­‐Security
-­‐
mish
mash
of
HTTP
Basic,
HTTP
Digest,
password,
and
SSL
for
message
authen+ca+on
• Nothing
comparable
to
WS-­‐Trust
–
consequently
client
bears
burden
of
managing
creden+als
&
trust

7. 2)
Password
an+-­‐paKern
Site
asks
YOU
for
your
GOOGLE
password
so
it
can
access
your
Google
stuff.

8. Tsk
tsk!
• Teaches
users
to
be
indiscriminate
with
their
passwords
• Doesn’t
support
granular
permissions,
e.g.
X
can
read
but
not
write
• Doesn’t
support
(easy)
revoca+on
–
to
be
sure
of
turning
off
access
users
must
change
password

9. Importance
of
revoca+on
This
is
shiny!!!!!
I
should
use
that
more
WTF
is
this
thing?

10. 3)
Cloud
APIs
• Within
move
towards
SaaS
–
trend
towards
API
access
to
data/services
to
supplement/replace
browser
access
• Salesforce.com expects that within the next year –
only 1/3 of access will be via browser
• APIs
of
PaaS
offerings
allow
the
customer
to
expose
its
own
cloud
services
• Clear
trend
for
these
APIs
is
towards
REST

11. Cloud
cures
everything

12. 4)
Na+ve
mobile
apps

13. Drivers
Password
Lack
of
an+-­‐
standards
paKern
OAuth
Na+ve
mobile
Cloud
APIs
Applica+ons

14. OAuth 2.0
• Defines
authoriza+on
&
authen+ca+on
framework
for
RESTful
APIs
• Approaching
final
standardiza+on
in
IETF
• Applied
to
delegated
authoriza+on
–
mi+gates
password
an+-­‐paKern
-­‐
archetypical
use
case
• Also
applicable
to
many
other
scenarios
–
even
those
with
no
users
• Notable
for
its
op+miza+ons
for
mobile

16. Mobile
app
IdM
architecture

17. Na+ve
vs
web
apps
• Not
going
to
try
to
predict
winner
–
expect
both
• Authen+ca+on
&
authoriza+on
should
be
consistent
across
both
models,
so
that
– Users
are
not
confused,
eg
use
different
creden+als
and/or
authen+ca+on
ceremony
for
the
two
models,
even
if
accessing
the
same
applica+on
– Service
Providers
aren’t
forced
to
implement
duplicate
&
incompa+ble
security
frameworks
for
the
two
models

18. Federa+on
• Federa+on
abstracts
away
from
applica+ons
specifics
of
authen+ca+on
&
authoriza+on
–
outsourced
to
specialized
providers
• Complexity
hidden
by
token
issuance
&
valida+on
• Federa+on
standards
define
– Token
formats
– How
clients
obtain
tokens
– How
clients
present
tokens
to
applica+on
providers

19. Tokens
• Federated
authen+ca+on
for
both
web
and
na+ve
mobile
applica+ons
is
based
on
exchange
and
delivery
of
tokens
to
the
applica+on
• Tokens
carry
(or
point
to)
security
informa+on
(like
aKributes
or
authoriza+ons)
for
user
trying
to
access
the
applica+on.
• Clients
typically
exchange
creden+als
for
tokens
-­‐
easier/safer
to
share
the
token
across
the
network
rather
than
the
original
creden+als
• When
token
is
subsequently
presented
to
an
applica+on
provider,
they
serve
to
authen+cate
and/or
authorize
the
request

20. Federa+on
takes
different
forms
For
web
apps,
tokens
carry
Browser
app
AKributes
for
authen+ca+on
For
na+ve
apps,
tokens
carry
app
data
Authoriza+on
for
aKributes

21. Tokens
for
mobile
web
applica+ons
• Federa+on
for
web
applica+ons
manifests
as
SSO
from
some
IdP
to
the
applica+on
provider
• SSO
especially
relevant
for
mobile
• Tokens
aKes+ng
to
the
user’s
iden+ty
and/or
authen+ca+on
status
delivered
through
(as
redirects)
the
browser
from
IdP
to
the
applica+on
provider
• Applica+on
provider
validates
token
and
extracts
iden+ty
aKributes
from
within
in
order
to
create
local
session

22. Tokens
for
web
applica+ons
Iden+ty
provider
Service
provider
1. User
trades
creden+als
for
a
token
from
IdP
SAML
2. Token
delivered
OpenID
Applica+on
through
the
browser
to
SP
3. SP
validates
token,
and
delivers
applica+on
HTML
Pwd
HTML
to
browser
Token
Device
Browser

23. Best
prac+ces
• Standards
– OpenID
2.0
for
consumer
scenarios
– SAML
2.0
for
enterprise
&
cloud
– WS-­‐Federa+on
for
homogeneous
MSFT
• IdP
Discovery
– In
consumer
space,
consider
Nascar
with
email-­‐
based
supplement
– In
cloud
space,
consider
email-­‐based
• Both
IdP
(portal)
and
SP
(deep-­‐linking)
ini+ated
are
relevant
• Mobile
browser
constraints
may
recommend
ar+fact
model
in
SAML

24. Tokens
for
na+ve
applica+ons
• Na+ve
applica+ons
authen+cate
to
REST
APIs
by
presen+ng
a
token
on
the
call
• The
precursor
act
of
the
na+ve
applica+on
obtaining
a
token
is
oeen
called
‘authoriza+on’
(par+cularly
in
those
cases
when
the
API
fronts
user
info,
eg
profile,
tweets,
etc)
• User
authorizes
(or
consents)
to
the
na+ve
applica+on
having
access
to
the
API
(and
their
data)
–
the
authoriza+on
is
manifested
as
the
issuance
of
a
token
to
the
na+ve
app
• OAuth
2.0
dominant
protocol
by
which
a
na+ve
app
obtains
the
desired
authoriza+ons
and
the
corresponding
token
(and
then
uses
against
API)

25. Mobile
authn
op+ons
• Pwd
shared
with
3rd
party
Embedded
browser
Inline
• App
owns
UI
• No
need
to
leave
app
• Custom
scheme
• Enables
SSO
• Enables
strong
authn
• AS
owns
UI
• Visual
trust
cues
• Can
leverage
stored
pwds
External
browser

26. Tokens
for
na+ve
applica+ons
Service
provider
1. User
trades
creden+als
for
a
token
2. Token
delivered
through
the
browser
to
na+ve
applica+on
Applica+on
3. Na+ve
applica+on
presents
token
on
API
calls
4. Applica+on
returns
applica+on
data
as
JSON
Pwd
Token
JSON/XML
Device
Browser
Applica+on
OAuth

27. Best
prac+ces
• Use
the
browser
to
authen+cate
the
user
to
the
AS,
don’t
collect
user
passwords
within
na+ve
applica+on
itself
• A
separate
browser
window
preferred
to
embedded
–
gives
user
the
visual
trust
cues
trained
to
look
for
• OAuth
authoriza+on
code
grant
type
is
relevant
–
allows
a
refresh
token
to
be
delivered
to
the
na+ve
applica+on
(obviates
need
to
con+nually
reauthorize)
• Use
browser
for
IdP
discovery
if
doing
SSO
(rather
than
within
na+ve
applica+on
itself)
• Na+ve
applica+on
should
register
custom
scheme
on
install,
to
enable
subsequent
passing
of
token
from
browser
back
to
na+ve
applica+on

28. Walk
through
• Walk
through
scenario
of
an
employee
using
a
na+ve
app
on
their
phone/tablet
to
interact
with
a
SaaS
provider
• SAML
provides
– Authen+ca+on
of
employee
to
SaaS
provider
• OAuth
provides
– authoriza+on
of
na+ve
app
to
access
SaaS
APIs
– Issuance
of
tokens
from
SaaS
to
na+ve
app

29. Walk
through
OAuth
SAML
OAuth

30. Load
authz
page

31. Load
authz
page

32. Load
authz
page
GET
/as/authoriza+on.oauth2?
client_id=mobileapp&state=abc123&redirect_uri=mobileapp://
redirect_here&response_type=code
HTTP/1.1
Note
-­‐ -­‐
No
client
pwd
-­‐ -­‐
custom
scheme
on
redirect
URL
-­‐ -­‐
response
type
of
‘code’

33. IdP
Discovery

34. IdP
Discovery

35. IdP
discovery

36. SSO
Request

37. SSO
request

38. SSO
Request
<form
method="post"
ac+on="hKps://idp.example.org/SAML2/SSO/POST"
>
<input
type="hidden"
name="SAMLRequest"
value="request"
/>
<input
type="submit"
value="Submit"
/>
</form>
<samlp:AuthnRequest
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:asser+on"
ID="aaf23196-­‐1773-­‐2113-­‐474a-­‐
fe114412ab72"
Version="2.0"
IssueInstant="2004-­‐12-­‐05T09:21:59Z”>
<saml:Issuer>hKps://sp.example.com/SAML2</saml:Issuer>
<samlp:NameIDPolicy
AllowCreate="true"
Format="urn:oasis:names:tc:SAML:
2.0:nameid:format:persistent"/>
</samlp:AuthnRequest>

39. User
authen+ca+on

40. User
authen+ca+on

41. User
authen+ca+on

42. SSO
response

43. SSO
Response

44. SSO
Response
<saml:Asser+on>
<saml:Issuer>hKps://idp.example.org/SAML2</saml:Issuer>
<ds:Signature
xmlns:ds="hKp://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
<saml:Subject>
<saml:NameID
Format="urn:oasis:names:tc:SAML:2.0:nameid-­‐format:persistent">
3f7b3dcf-­‐1674-­‐4ecd-­‐92c8-­‐1544f346baf8
</saml:NameID></saml:Subject>
<saml:AKributeStatement>
<saml:AKribute
Name=“email”
>
<saml:AKributeValue
xsi:type="xs:string">pmadsen@pingiden+ty.com</saml:AKributeValue>
</saml:AKribute>
</saml:AKributeStatement>
</saml:Asser+on>

45. Response
with
code

46. Response
with
code

47. Response
with
code
HTTP/1.1
302
Found
Loca+on:
mobileapp://redirect_here?
state=abc123&
code=wizJmaSTPAf0wqSeB3vmDx2mNSZK6g
Content-­‐Length:
0

48. Trade
code
for
token

49. Trade
code
for
token

50. Trade
code
for
token
GET
/as/token.oauth2?client_id=a&redirect_uri=mobileapp://
redirecthere&grant_type=authoriza+on_code&code=wizJmaSTPAf0wqSeB3vmDx2
mNSZK6g
HTTP/1.1
Host:
as.com
Accept:
*/*
HTTP/1.1
200
OK
Content-­‐Type:
applica+on/json;
charset=UTF-­‐8
{"token_type":"Bearer","expires_in":"60","refresh_token":"oQWqwMUIL2ndeMHsWEy
FO0GyalvKSvc2QI4YuG82RMGkM","access_token":"lSBbci4Jg8MsjiSqZLBrzEXgd4m
KUNhOkyF"}

51. Client
calls
API

52. Client
calls
API

53. Client
calls
API
hKps://graph.facebook.com/paul.e.madsen/
friends/?
access_token=lSBbci4Jg8MsjiSqZLBrzEXgd4mK
UNhOkyF

54. Verify
token

55. Verify
token

56. Verify
token
GET
/as/token.oauth2?
client_id=b&client_secret=pwd&grant_type=urn:ping:validate&token=lSBbci4Jg8MsjiSqZLBrzEXgd4mKUNhOkyF
HTTP/1.1
Host:
as.com
Accept:
*/*
HTTP/1.1
200
OK
Content-­‐Type:
applica+on/json;
charset=UTF-­‐8
Not
OAuth
defined

57. Return
Data

58. Return
Data

59. Return
data
HTTP/1.1
200
OK
Content-­‐Type:
applica+on/json;
charset=UTF-­‐8

60. Time
passes

61. Refresh
token

62. Refresh
token

63. Refresh
token
GET
/as/token.oauth2?
client_id=a&grant_type=refresh_token&refresh_token=oQWqwMUIL2nde
MHsWEyFO0GyalvKSvc2QI4YuG82RMGkM
HTTP/1.1
Host:
localhost:9031
Accept:
*/*
HTTP/1.1
200
OK
Content-­‐Type:
applica+on/json;
charset=UTF-­‐8
{"token_type":"Bearer","expires_in":"60","refresh_token":"JZ7Qa4yH5C8E3Cik
vcZZsd4ZLUgVyYnieXqybAFjObQpz","access_token":"49BPI5LuNM310o7h
bB9m9cIzImT5M8gcRjE"}

64. Thanks
Paul
Madsen
@paulmadsen