API Security & Federation Patterns - Francois Lascelles, Chief Architect, Layer 7 @ QCon SF

API Security and
Federation Patterns
QCon San Francisco - November 13, 2013
Francois Lascelles, Chief Architect, Layer 7 Technologies

#qconsf
#OAuth
@flascelles

Agenda
 Introduction
 API Security Components
 Authorization Server Patterns
–
–
–
–
–

Two-way token issuing
Redirection-based token issuing
Nested handshakes
Federated handshakes
Other extension handshakes

 Vulnerabilities and Mitigation
– Fishing attacks
– Public vs Confidential clients
– Bearer vs MAC token types

 Managing API Security
2

API Security and Federation Patterns

Information fragmentation
– Users and organizations interact with IT assets fragmented across
an increasing number of service providers, applications and
devices

Your Org

– In isolation, each asset provides limited value
3


Application-to-application interaction

– APIs let providers and applications interact
 HTTP
 REST

 OData
 XML/JSON
 Web Services

4


Secure API exchange

– These APIs deal with personal and/or sensitive information and need to
be secured
 Confidentiality
 Integrity
 Availability
 …

5


Interactions on behalf of users

– OAuth lets users and organizations control these interactions
 Express consent
 Limit scope
 Turn on/off

6


API security logical components

IdP

User

Authorization Server
Application

Token Server
Policy Enforcement Point
Resource Server

7


API Endpoint

Authorization server patterns

Let us count the ways…

8


Two-way handshakes
 Limit shared-secret exposure by negotiating temporary token

1. Authenticate with secret, get token

2. Consume API, include token in requests

9


E.g. OAuth client credentials grant type

 In this grant type, the application presents its own credentials
to get a token.
– No concept of user identity

 Alternatives
– Present client credentials with every API call (over secure channel)
– HMAC signatures for every API call

 Only for confidential clients
 No refresh token in this case

10


E.g. OAuth password grant type (ropc)
 Resource-owner password credentials
– For trusted apps only
– For public or confidential clients
– Optimal UX on mobile apps
1. App collects user credentials

POST /token
[Authorization: Basic optional]
Content-Type: application/x-www-form-urlencoded
grant_type=password&username=franco&password=bl
ah

Email:
_______
Passwd: _______
[Login]

3. App gets back token(s)
Content-Type: application/json
{
"access_token":”foo”,
"expires_in":3600,
["refresh_token":”optional”]
11

2. App uses creds in call to token
endpoint

}


Redirection-based handshakes

12


Redirection-based handshakes – Why?
 Avoid the password sharing anti-pattern

Online
statement

Pretend to be user
Pull statement

Please provide your cc account info:
• Username
• Password

This seems
wrong

13

Expense
system


RBH – step 1

(Authorization server)

Authenticate locally (if needed)
Express consent

14

Redirect


RBH – step 2

- User did not share
passwd with app
(callback address)

Redirect
back

15

Receive
code


RBH – step 3

tmp code

I can haz
token?

access token

Call API
(with token)

- Application now accesses

Much
better…
16

data on behalf of user


E.g. OAuth 2.0 code, implicit

OAuth 2.0 core specifies two variations on a redirection-based
handshake
1. Authorization code
–

As we just described

2. Implicit
– No temporary code
– App gets token directly through redirect back from authorization server

17


Social Login
 An application delegates user authentication to a social
platform
– Enhanced user experience
– Remove burden of managing shared secrets with users

18


Social Login – Step 1

 User click Login with [Social provider]
– Redirected to Social provider’s authorization server

 User authenticated, expresses consent

Do you authorize app to get basic info
about you?
Yes [x]
No [ ]

19



 User expresses consent
– Redirected back to the application
– Application now has OAuth access token to call API on behalf of user

++token

20



 App calls [Social provider]’s api
– User_info endpoint
– Discovers identity of user
– Attaches it to session between app and user-agent

Who was this? [access_token]
user_info

21

{ ‘sub’: ‘franco’, ‘email’: ‘flascelles@gmail.com’…}


Social Login -> OpenID Connect
 In this case, the API provided is there to enable the federated
authentication

 This pattern is specified in standard OpenID Connect
– Extends OAuth 2.0
– Describes user_info, ID token based on JWT, …

 Web-friendly and modern alternative to SAML web browser
SSO
– No SAML, no XML, no digital signatures,…

API Provider -> IdP
22


Nested handshakes
 When users interact with an authorization server, they need to
be authenticated

 What happens when the API provider wants to delegate
authentication to a social login/openid connect provider?

Username: _________
Password: _________ [Login]

Log in with [Google] [facebook] […]

23


Step 1
App wants to consume API
on behalf of user, redirects
to API provider’s
authorization server to get
back access token

app

Nested handshakes

Step 2
User redirected to IdP of choice so that the first
authorization server gets an access token from the
2nd authorization server

app
Do you authorize app* to get basic info
about you?
Yes [x]
No [ ]

24


Nested handshakes

Step 3
User redirected back, its identity now known to the
first authorization server, expresses consent.

Do you authorize app* to [scope] on
your behalf?
Yes [x]
No [ ]

25


app

Nested handshakes

Step 4
User redirected back to app. Nested handshakes
complete.

Two apps, two access tokens

26



 Application already has a ‘proof-of-authentication’, needs to
consume API on behalf of user
– Login using SAML on a web app
– OpenID Connect

 No redirection, no credentials

<saml>
{jwt}

27

?


 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


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


Other ‘extension’ handshakes

 Challenge-response grant
– One-time passwords

– Risk-based, context-based auth
– Multi-factor

 [Insert Secret] bearer grant
– Cookie
– …

30


Threats and Mitigation

31


Fishing attacks
 Risk associated with redirection-based handshakes
– Malicious ‘application’ pretends to be legitimate
– Inserts its own endpoint in callback address
– Gets token

 (especially implicit grant)
Do you authorize Legitimate
app to access API on your
behalf?

Tricked
you

[X] Yes
[ ] No

GET
/authorize?response_type=token&client_id=legitimate
&redirect_uri=[malicious]
32


Fishing mitigation 101
 Register and validate redirection URIs
 Strict validation (not partial)

 Never skip consent step
(out-of-band)
Register Legitimate app
Callback=foo

foiled
Error
Invalid callback
GET
/authorize?response_type=token&client_id=legitimate
&redirect_uri=[malicious]
33


Fishing on mobile
 On the web, the user-agent is responsible for redirecting to
the callback address
– On the web, DNS resolves addresses and HTTPS validates server-side
trust

 With native 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


Public vs confidential clients

 It’s either confidential, or it isn’t
– Don’t ‘hide’ a secret on a public app
store or render on a web page

(badly hidden witch)

35


Client confidentiality does strengthen security

 Assigned secrets to clients (when appropriate) adds security
– E.g. compromised refresh token:

1. Compromised
access tokens,
refresh
foiled tokens

2. Exploit stolen
token for x
minutes
3. Token expired

4. Attempt to get fresh token
(using refresh token)

5. Authentication required
36


Bearer vs MAC tokens

 Bearer

 MAC

Adoption!

Tough
choice

App developer
37


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


MAC, is it really more secure?
 Pros
– Better 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


Managing API Security

Extend
framework to
client app

Integrate

•
•
•
•
•

Authorization Server
Policy Enforcement Point
Resource Server
ALFW
…

Protect

Configure, not
code
40


•
•
•
•

Web SSO
Analytics
Dev/User Portal
…

Decouple

Thank you

QCon SF 2013
Francois Lascelles, Chief Architect, Layer 7 Technologies

API Security & Federation Patterns - Francois Lascelles, Chief Architect, Layer 7 @ QCon SF

Recommended

More Related Content

What's hot (20)

Similar to API Security & Federation Patterns - Francois Lascelles, Chief Architect, Layer 7 @ QCon SF (20)

More from CA API Management (20)

Recently uploaded (20)

API Security & Federation Patterns - Francois Lascelles, Chief Architect, Layer 7 @ QCon SF

Editor's Notes