Video and slides synchronized, mp3 and slide download available at URL http://bit.ly/1iq4lYa. Francois Lascelles examines the role of API management infrastructure in API Security, API Access Control and API Federation and its interaction with enterprise infrastructure, social identity and application developers. Filmed at qconsf.com. Francois Lascelles is a subject matter expert on API security and the application of standards such as OAuth and OpenID Connect. As Layer 7’s Chief Architect, he guides the solutions architecture team and aligns product evolution with field trends. Francois joined Layer 7 in the company’s infancy – contributing as the first developer and designing the foundation of Layer 7’s Gateway technology.

1. API
Security
and
Federa1on
Pa3erns
QCon
San
Francisco
-­‐
November
13,
2013
Francois
Lascelles,
Chief
Architect,
Layer
7
Technologies
#qconsf
#OAuth
@flascelles

2. Watch the video with slide
synchronization on InfoQ.com!
http://www.infoq.com/presentations
/api-security-federation-patterns
InfoQ.com: News & Community Site
• 750,000 unique visitors/month
• Published in 4 languages (English, Chinese, Japanese and Brazilian
Portuguese)
• Post content from our QCon conferences
• News 15-20 / week
• Articles 3-4 / week
• Presentations (videos) 12-15 / week
• Interviews 2-3 / week
• Books 1 / month

3. Presented at QCon San Francisco
www.qconsf.com
Purpose of QCon
- to empower software development by facilitating the spread of
knowledge and innovation
Strategy
- practitioner-driven conference designed for YOU: influencers of
change and innovation in your teams
- speakers and topics driving the evolution and innovation
- connecting and catalyzing the influencers and innovators
Highlights
- attended by more than 12,000 delegates since 2007
- held in 9 cities worldwide

4. Agenda
§ Introduc1on
§ API
Security
Components
§ Authoriza1on
Server
Pa3erns
–
–
–
–
–
Two-­‐way
token
issuing
Redirec1on-­‐based
token
issuing
Nested
handshakes
Federated
handshakes
Other
extension
handshakes
§ Vulnerabili1es
and
Mi1ga1on
– Fishing
a3acks
– Public
vs
Confiden1al
clients
– Bearer
vs
MAC
token
types
§ Managing
API
Security
2
API
Security
and
Federa1on
Pa3erns

5. Informa=on
fragmenta=on
– Users
and
organiza1ons
interact
with
IT
assets
fragmented
across
an
increasing
number
of
service
providers,
applica1ons
and
devices
Your
Org
– In
isola1on,
each
asset
provides
limited
value
3
API
Security
and
Federa1on
Pa3erns

6. Applica=on-­‐to-­‐applica=on
interac=on
– APIs
let
providers
and
applica1ons
interact
§ HTTP!
§ REST!
§ OData!
§ XML/JSON!
§ Web Services!
4
API
Security
and
Federa1on
Pa3erns

7. Secure
API
exchange
– These
APIs
deal
with
personal
and/or
sensi1ve
informa1on
and
need
to
be
secured
§ Confiden1ality
§ Integrity
§ Availability
§ …
5
API
Security
and
Federa1on
Pa3erns

8. Interac=ons
on
behalf
of
users
– OAuth
lets
users
and
organiza1ons
control
these
interac1ons
§ Express
consent
§ Limit
scope
§ Turn
on/off
6
API
Security
and
Federa1on
Pa3erns

9. API
security
logical
components
IdP
User
Authoriza1on
Server
Applica1on
Token
Server
Policy
Enforcement
Point
Resource
Server
7
API
Security
and
Federa1on
Pa3erns
API
Endpoint

10. Authoriza=on
server
paGerns
Let
us
count
the
ways…
8
API
Security
and
Federa1on
Pa3erns

11. Two-­‐way
handshakes
§ Limit
shared-­‐secret
exposure
by
nego1a1ng
temporary
token
1.
Authen1cate
with
secret,
get
token
2.
Consume
API,
include
token
in
requests
9
API
Security
and
Federa1on
Pa3erns

12. E.g.
OAuth
client
creden=als
grant
type
§ In
this
grant
type,
the
applica1on
presents
its
own
creden1als
to
get
a
token.
– No
concept
of
user
iden1ty
§ Alterna1ves
– Present
client
creden1als
with
every
API
call
(over
secure
channel)
– HMAC
signatures
for
every
API
call
§ Only
for
confiden1al
clients
§ No
refresh
token
in
this
case
10
API
Security
and
Federa1on
Pa3erns

13. E.g.
OAuth
password
grant
type
(ropc)
§ Resource-­‐owner
password
creden1als
– For
trusted
apps
only
– For
public
or
confiden1al
clients
– Op1mal
UX
on
mobile
apps
1.
App
collects
user
creden1als
POST /token!
[Authorization: Basic optional]!
Content-Type: application/x-www-formurlencoded!
grant_type=password&username=franco&pass
word=blah!
Email:
_______
Passwd:
_______
[Login]
3.
App
gets
back
token(s)
Content-Type: application/json
{
11
2.
App
uses
creds
in
call
to
token
endpoint
"access_token":”foo”,
"expires_in":3600,
["refresh_token":”optional”]
}!
API
Security
and
Federa1on
Pa3erns

14. Redirec=on-­‐based
handshakes
12
API
Security
and
Federa1on
Pa3erns

15. Redirec=on-­‐based
handshakes
–
Why?
§ Avoid
the
password
sharing
an1-­‐pa3ern
Online
statement
Pretend
to
be
user
Pull
statement
Please
provide
your
cc
account
info:
• Username
• Password
This
seems
wrong
13
Expense
system
API
Security
and
Federa1on
Pa3erns

16. RBH
–
step
1
(Authoriza1on
server)
Authen1cate
locally
(if
needed)
Express
consent
14
Redirect
API
Security
and
Federa1on
Pa3erns

17. RBH
–
step
2
-­‐
User
did
not
share
passwd
with
app
Redirect
back
15
Receive
code
API
Security
and
Federa1on
Pa3erns
(callback
address)

18. RBH
–
step
3
tmp
code
I
can
haz
token?
access
token
Call
API
(with
token)
-­‐
Applica1on
now
accesses
Much
be3er…
16
data
on
behalf
of
user
API
Security
and
Federa1on
Pa3erns

19. E.g.
OAuth
2.0
code,
implicit
OAuth
2.0
core
specifies
two
varia1ons
on
a
redirec1on-­‐based
handshake
1. Authoriza1on
code
–
As
we
just
described
2. Implicit
– No
temporary
code
– App
gets
token
directly
through
redirect
back
from
authoriza1on
server
17
API
Security
and
Federa1on
Pa3erns

20. Social
Login
§ An
applica1on
delegates
user
authen1ca1on
to
a
social
plamorm
– Enhanced
user
experience
– Remove
burden
of
managing
shared
secrets
with
users
18
API
Security
and
Federa1on
Pa3erns

21. Social
Login
–
Step
1
§ User
click
Login
with
[Social
provider]
– Redirected
to
Social
provider’s
authoriza1on
server
§ User
authen1cated,
expresses
consent
Do
you
authorize
app
to
get
basic
info
about
you?
Yes
[x]
No
[
]
19
API
Security
and
Federa1on
Pa3erns

22. Social
Login
–
Step
2
§ User
expresses
consent
– Redirected
back
to
the
applica1on
– Applica1on
now
has
OAuth
access
token
to
call
API
on
behalf
of
user
++token
20
API
Security
and
Federa1on
Pa3erns

23. Social
Login
–
Step
3
§ App
calls
[Social
provider]’s
api
– User_info
endpoint
– Discovers
iden1ty
of
user
– A3aches
it
to
session
between
app
and
user-­‐agent
Who
was
this?
[access_token]
user_info
21
{
‘sub’:
‘franco’,
‘email’:
‘flascelles@gmail.com’…}
API
Security
and
Federa1on
Pa3erns

24. Social
Login
-­‐>
OpenID
Connect
§ In
this
case,
the
API
provided
is
there
to
enable
the
federated
authen1ca1on
§ This
pa3ern
is
specified
in
standard
OpenID
Connect
– Extends
OAuth
2.0
– Describes
user_info,
ID
token
based
on
JWT,
…
§ Web-­‐friendly
and
modern
alterna1ve
to
SAML
web
browser
SSO
– No
SAML,
no
XML,
no
digital
signatures,…
API
Provider
-­‐>
IdP
22
API
Security
and
Federa1on
Pa3erns

25. Nested
handshakes
§ When
users
interact
with
an
authoriza1on
server,
they
need
to
be
authen1cated
§ What
happens
when
the
API
provider
wants
to
delegate
authen1ca1on
to
a
social
login/openid
connect
provider?
Username:
_________
Password:
_________
[Login]
Log
in
with
[Google]
[facebook]
[…]
23
API
Security
and
Federa1on
Pa3erns
Step
1
App
wants
to
consume
API
on
behalf
of
user,
redirects
to
API
provider’s
authoriza1on
server
to
get
back
access
token
app

26. Nested
handshakes
Step
2
User
redirected
to
IdP
of
choice
so
that
the
first
authoriza1on
server
gets
an
access
token
from
the
2nd
authoriza1on
server
app
Do
you
authorize
app*
to
get
basic
info
about
you?
Yes
[x]
No
[
]
24
API
Security
and
Federa1on
Pa3erns

27. Nested
handshakes
Step
3
User
redirected
back,
its
iden1ty
now
known
to
the
first
authoriza1on
server,
expresses
consent.
Do
you
authorize
app*
to
[scope]
on
your
behalf?
Yes
[x]
No
[
]
25
API
Security
and
Federa1on
Pa3erns
app

28. Nested
handshakes
Step
4
User
redirected
back
to
app.
Nested
handshakes
complete.
Two
apps,
two
access
tokens
26
API
Security
and
Federa1on
Pa3erns

29. Federated
handshakes
§ Applica1on
already
has
a
‘proof-­‐of-­‐authen1ca1on’,
needs
to
consume
API
on
behalf
of
user
– Login
using
SAML
on
a
web
app
– OpenID
Connect
§ No
redirec1on,
no
creden1als
<saml>
{jwt}
27
?
API
Security
and
Federa1on
Pa3erns

30. Federated
handshakes
§ SAML
Bearer
Grant
– urn:ietf:params:oauth:grant-type:samXX-bearer
<saml>
access_token
§ JWT
Bearer
Grant
– urn:ietf:params:oauth:grant-type:jwt-bearer
{jwt}
access_token
28
API
Security
and
Federa1on
Pa3erns

31. Example:
Domain
of
apps
sharing
an
auth
context
§ A
domain
of
apps
on
a
mobile
device
share
an
auth
context
– OpenID
Connect
-­‐>
JWT
§ Each
app
gets
its
own
access
token
– urn:ietf:params:oauth:grant-type:jwt-bearer!
§ Single
sign-­‐on
experience
OpenID
Connect
JWT
Bearer
Grant
Group
KeyChain
API
Provider
Mobile
apps
29
API
Security
and
Federa1on
Pa3erns

32. Other
‘extension’
handshakes
§ Challenge-­‐response
grant
– One-­‐1me
passwords
– Risk-­‐based,
context-­‐based
auth
– Mul1-­‐factor
§ [Insert
Secret]
bearer
grant
– Cookie
– …
30
API
Security
and
Federa1on
Pa3erns

33. Threats
and
Mi=ga=on
31
API
Security
and
Federa1on
Pa3erns

34. Fishing
aGacks
§ Risk
associated
with
redirec1on-­‐based
handshakes
– Malicious
‘applica1on’
pretends
to
be
legi1mate
– Inserts
its
own
endpoint
in
callback
address
– Gets
token
§ (especially
implicit
grant)
Do
you
authorize
Legi1mate
app
to
access
API
on
your
behalf?
[X]
Yes
[
]
No
Tricked
you
GET /authorize?
response_type=token&client_id=legitimate
&redirect_uri=[malicious]!
32
API
Security
and
Federa1on
Pa3erns

35. Fishing
mi=ga=on
101
§ Register
and
validate
redirec1on
URIs
§ Strict
valida1on
(not
par1al)
§ Never
skip
consent
step
(out-­‐of-­‐band)
Register
Legi1mate
app
Callback=foo
foiledL
Error
Invalid
callback
GET /authorize?
response_type=token&client_id=legitimate
&redirect_uri=[malicious]!
33
API
Security
and
Federa1on
Pa3erns

36. Fishing
on
mobile
§ On
the
web,
the
user-­‐agent
is
responsible
for
redirec1ng
to
the
callback
address
– On
the
web,
DNS
resolves
addresses
and
HTTPS
validates
server-­‐side
trust
§ With
na1ve
mobile
apps,
each
app
registers
its
own
URL
scheme
instead
APPLE:
“If more than one third-party app registers to handle
the same URL scheme, there is currently no process
for determining which app will be given that scheme. ”
--link
34
API
Security
and
Federa1on
Pa3erns

37. Public
vs
confiden=al
clients
§ It’s
either
confiden1al,
or
it
isn’t
– Don’t
‘hide’
a
secret
on
a
public
app
store
or
render
on
a
web
page
(badly
hidden
witch)
35
API
Security
and
Federa1on
Pa3erns

38. Client
confiden=ality
does
strengthen
security
§ Assigned
secrets
to
clients
(when
appropriate)
adds
security
– E.g.
compromised
refresh
token:
1.
Compromised
access
tokens,
refresh
foiledL
tokens
2.
Exploit
stolen
token
for
x
minutes
3.
Token
expired
4.
A3empt
to
get
fresh
token
(using
refresh
token)
5.
Authen1ca1on
required
36
API
Security
and
Federa1on
Pa3erns

39. Bearer
vs
MAC
tokens
§ Bearer
§ MAC
Adop=on!
Tough
choice
App
developer
37
API
Security
and
Federa1on
Pa3erns

40. Bearer,
use
responsibly
§ Bearer
tokens
are
easier
but
need
to
be
used
responsibly
– Exchanged
and
used
over
a
secure
channel
-­‐
Don’t
log
them.
-­‐
Forget
original
(hash
them).
tokens
in
query
strings
App
developer
API
Publisher
OAuth
Server
Impl
38
-­‐
Don’t
render
them
where
they
can
be
copied
from.
-­‐ Store
them
securely.
-­‐ Server-­‐side
trust
API
Security
and
Federa1on
Pa3erns

41. MAC,
is
it
really
more
secure?
§ Pros
– Be3er
protected
against
man-­‐in-­‐the-­‐middle
– If
a
request
is
intercepted,
no
big
deal
§ Cons
– You
have
to
keep
two
secrets
safe
on
the
server
side
(per
client)
39
API
Security
and
Federa1on
Pa3erns

42. Managing
API
Security
Extend
framework
to
client
app
Integrate
•
•
•
•
•
Authoriza1on
Server
Policy
Enforcement
Point
Resource
Server
ALFW
…
Protect
Configure,
not
code
40
API
Security
and
Federa1on
Pa3erns
•
•
•
•
Web
SSO
Analy1cs
Dev/User
Portal
…
Decouple

43. Thank
you
QCon
SF
2013
Francois
Lascelles,
Chief
Architect,
Layer
7
Technologies

44. Watch the video with slide synchronization on
InfoQ.com!
http://www.infoq.com/presentations/apisecurity-federation-patterns