Your SlideShare is downloading. ×
0
API Security and
Federation Patterns
QCon San Francisco - November 13, 2013
Francois Lascelles, Chief Architect, Layer 7 T...
Agenda
 Introduction
 API Security Components
 Authorization Server Patterns
–
–
–
–
–

Two-way token issuing
Redirecti...
Information fragmentation
– Users and organizations interact with IT assets fragmented across
an increasing number of serv...
Application-to-application interaction

– APIs let providers and applications interact
 HTTP
 REST

 OData
 XML/JSON
...
Secure API exchange

– These APIs deal with personal and/or sensitive information and need to
be secured
 Confidentiality...
Interactions on behalf of users

– OAuth lets users and organizations control these interactions
 Express consent
 Limit...
API security logical components

IdP

User

Authorization Server
Application

Token Server
Policy Enforcement Point
Resour...
Authorization server patterns

Let us count the ways…

8

API Security and Federation Patterns
Two-way handshakes
 Limit shared-secret exposure by negotiating temporary token

1. Authenticate with secret, get token

...
E.g. OAuth client credentials grant type

 In this grant type, the application presents its own credentials
to get a toke...
E.g. OAuth password grant type (ropc)
 Resource-owner password credentials
– For trusted apps only
– For public or confid...
Redirection-based handshakes

12

API Security and Federation Patterns
Redirection-based handshakes – Why?
 Avoid the password sharing anti-pattern

Online
statement

Pretend to be user
Pull s...
RBH – step 1

(Authorization server)

Authenticate locally (if needed)
Express consent

14

Redirect

API Security and Fed...
RBH – step 2

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

Redirect
back

15

Receive
code

API Security and F...
RBH – step 3

tmp code

I can haz
token?

access token

Call API
(with token)

- Application now accesses

Much
better…
16...
E.g. OAuth 2.0 code, implicit

OAuth 2.0 core specifies two variations on a redirection-based
handshake
1. Authorization c...
Social Login
 An application delegates user authentication to a social
platform
– Enhanced user experience
– Remove burde...
Social Login – Step 1

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

...
Social Login – Step 2

 User expresses consent
– Redirected back to the application
– Application now has OAuth access to...
Social Login – Step 3

 App calls [Social provider]’s api
– User_info endpoint
– Discovers identity of user
– Attaches it...
Social Login -> OpenID Connect
 In this case, the API provided is there to enable the federated
authentication

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

 What happens when t...
Nested handshakes

Step 2
User redirected to IdP of choice so that the first
authorization server gets an access token fro...
Nested handshakes

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

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

Two apps, two access tokens

26

API S...
Federated handshakes

 Application already has a ‘proof-of-authentication’, needs to
consume API on behalf of user
– Logi...
Federated handshakes
 SAML Bearer Grant
– urn:ietf:params:oauth:grant-type:samXX-bearer
<saml>
access_token

 JWT Bearer...
Example: Domain of apps sharing an auth context
 A domain of apps on a mobile device share an auth context
– OpenID Conne...
Other ‘extension’ handshakes

 Challenge-response grant
– One-time passwords

– Risk-based, context-based auth
– Multi-fa...
Threats and Mitigation

31

API Security and Federation Patterns
Fishing attacks
 Risk associated with redirection-based handshakes
– Malicious ‘application’ pretends to be legitimate
– ...
Fishing mitigation 101
 Register and validate redirection URIs
 Strict validation (not partial)

 Never skip consent st...
Fishing on mobile
 On the web, the user-agent is responsible for redirecting to
the callback address
– On the web, DNS re...
Public vs confidential clients

 It’s either confidential, or it isn’t
– Don’t ‘hide’ a secret on a public app
store or r...
Client confidentiality does strengthen security

 Assigned secrets to clients (when appropriate) adds security
– E.g. com...
Bearer vs MAC tokens

 Bearer

 MAC

Adoption!

Tough
choice

App developer
37

API Security and Federation Patterns
Bearer, use responsibly
 Bearer tokens are easier but need to be used responsibly
– Exchanged and used over a secure chan...
MAC, is it really more secure?
 Pros
– Better protected against man-in-the-middle
– If a request is intercepted, no big d...
Managing API Security

Extend
framework to
client app

Integrate

•
•
•
•
•

Authorization Server
Policy Enforcement Point...
Thank you

QCon SF 2013
Francois Lascelles, Chief Architect, Layer 7 Technologies
Upcoming SlideShare
Loading in...5
×

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

1,768

Published on

The adoption of Mobile and Cloud applications drives API traffic across domains. OAuth 2.0 is being implemented in complex enterprise environments where new authorization endpoints are combined with various existing identity components, in various configurations.

Handshakes are federated to help provide a single sign-on experience across applications and enhance adoption. Mediation between tokens at the edge of each domain helps extend existing data to new channels. Core grant types, extension grant types, custom schemes, standards, patterns and use cases – let us count the ways in which API access control is applied.

This presentation will examine 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.

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,768
On Slideshare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
77
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide
  • Think M2M
  • 12.30
  • This is very similar to saml web browsersso except that there is no complex saml to parse and digital signatures to validate
  • 25m
  • Show a domain of apps sharing a auth context in the form of a JWT issued from an openid connect handshake, then each app getting its own access token based on thatWeb-&gt;domain cookieMobile apps -&gt; a JWT stored in a shared keychain-&gt; ‘Mobile SSO’, ‘Layer 7 MAG”
  • 37.30
  • Transcript of "API Security & Federation Patterns - Francois Lascelles, Chief Architect, Layer 7 @ QCon SF"

    1. 1. API Security and Federation Patterns QCon San Francisco - November 13, 2013 Francois Lascelles, Chief Architect, Layer 7 Technologies #qconsf #OAuth @flascelles
    2. 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. 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. 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. 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. 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. 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. 8. Authorization server patterns Let us count the ways… 8 API Security and Federation Patterns
    9. 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. 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. 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. 12. Redirection-based handshakes 12 API Security and Federation Patterns
    13. 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. 14. RBH – step 1 (Authorization server) Authenticate locally (if needed) Express consent 14 Redirect API Security and Federation Patterns
    15. 15. RBH – step 2 - User did not share passwd with app (callback address) Redirect back 15 Receive code API Security and Federation Patterns
    16. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 31. Threats and Mitigation 31 API Security and Federation Patterns
    32. 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. 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. 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. 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. 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. 37. Bearer vs MAC tokens  Bearer  MAC Adoption! Tough choice App developer 37 API Security and Federation Patterns
    38. 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. 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. 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. 41. Thank you QCon SF 2013 Francois Lascelles, Chief Architect, Layer 7 Technologies
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×