This document summarizes an API security and federation patterns presentation given at QCon San Francisco in 2013. It discusses common API security components like authorization servers and resource servers. It then covers various authorization server patterns for issuing access tokens, including two-way token issuing, redirection-based token issuing, nested handshakes, and federated handshakes. It also discusses vulnerabilities like phishing attacks and ways to mitigate risks. Finally, it briefly touches on managing API security through frameworks that integrate authorization servers and other components.

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

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

3. 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
API Security and Federation Patterns

4. Application-to-application interaction
– APIs let providers and applications interact
 HTTP
 REST
 OData
 XML/JSON
 Web Services
4
API Security and Federation Patterns

5. Secure API exchange
– These APIs deal with personal and/or sensitive information and need to
be secured
 Confidentiality
 Integrity
 Availability
 …
5
API Security and Federation Patterns

6. Interactions on behalf of users
– OAuth lets users and organizations control these interactions
 Express consent
 Limit scope
 Turn on/off
6
API Security and Federation Patterns

7. API security logical components
IdP
User
Authorization Server
Application
Token Server
Policy Enforcement Point
Resource Server
7
API Security and Federation Patterns
API Endpoint

8. Authorization server patterns
Let us count the ways…
8
API Security and Federation Patterns

9. 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
API Security and Federation Patterns

10. 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
API Security and Federation Patterns

11. 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
}
API Security and Federation Patterns

12. Redirection-based handshakes
12
API Security and Federation Patterns

13. 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
API Security and Federation Patterns

14. RBH – step 1
(Authorization server)
Authenticate locally (if needed)
Express consent
14
Redirect
API Security and Federation Patterns

15. RBH – step 2
- User did not share
passwd with app
(callback address)
Redirect
back
15
Receive
code
API Security and Federation Patterns

16. 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
API Security and Federation Patterns

17. 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
API Security and Federation Patterns

18. Social Login
 An application delegates user authentication to a social
platform
– Enhanced user experience
– Remove burden of managing shared secrets with users
18
API Security and Federation Patterns

19. 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
API Security and Federation Patterns

20. Social Login – Step 2
 User expresses consent
– Redirected back to the application
– Application now has OAuth access token to call API on behalf of user
++token
20
API Security and Federation Patterns

21. Social Login – Step 3
 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’…}
API Security and Federation Patterns

22. 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
API Security and Federation Patterns

23. 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
API Security and Federation Patterns
Step 1
App wants to consume API
on behalf of user, redirects
to API provider’s
authorization server to get
back access token
app

24. 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
API Security and Federation Patterns

25. 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
API Security and Federation Patterns
app

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

27. Federated handshakes
 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
?
API Security and Federation Patterns

28. 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 Federation Patterns

29. 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 Federation Patterns

30. Other ‘extension’ handshakes
 Challenge-response grant
– One-time passwords
– Risk-based, context-based auth
– Multi-factor
 [Insert Secret] bearer grant
– Cookie
– …
30
API Security and Federation Patterns

31. Threats and Mitigation
31
API Security and Federation Patterns

32. 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
API Security and Federation Patterns

33. 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
API Security and Federation Patterns

34. 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
API Security and Federation Patterns

35. 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
API Security and Federation Patterns

36. 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
API Security and Federation Patterns

37. Bearer vs MAC tokens
 Bearer
 MAC
Adoption!
Tough
choice
App developer
37
API Security and Federation Patterns

38. 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 Federation Patterns

39. 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
API Security and Federation Patterns

40. Managing API Security
Extend
framework to
client app
Integrate
•
•
•
•
•
Authorization Server
Policy Enforcement Point
Resource Server
ALFW
…
Protect
Configure, not
code
40
API Security and Federation Patterns
•
•
•
•
Web SSO
Analytics
Dev/User Portal
…
Decouple

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