api security & federation patterns - francois lascelles, chief architect, layer 7 @ qcon sf

API Security and Federation Patterns

QCon San Francisco - November 13, 2013Francois Lascelles, Chief Architect, Layer 7 Technologies

#qconsf

#OAuth

@flascelles

2 API Security and Federation Patterns

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


Information fragmentation

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

– In isolation, each asset provides limited value

Your Org


Application-to-application interaction

– APIs let providers and applications interact

HTTP

REST

OData

XML/JSON

Web Services


Secure API exchange

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


Interactions on behalf of users

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


API security logical components

IdP

Authorization Server

Application

Resource Server API Endpoint

Token Server

Policy Enforcement Point

User


Authorization server patterns

Let us count the ways…


Two-way handshakes

1. Authenticate with secret, get token

2. Consume API, include token in requests

Limit shared-secret exposure by negotiating temporary token


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


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

3. App gets back token(s)

2. App uses creds in call to token endpoint

Email: _______Passwd: _______

[Login]

POST /token[Authorization: Basic optional]Content-Type: application/x-www-form-urlencodedgrant_type=password&username=franco&password=blah

Content-Type: application/json

{ "access_token":”foo”, "expires_in":3600, ["refresh_token":”optional”]}


Redirection-based handshakes


Redirection-based handshakes – Why?

Avoid the password sharing anti-pattern

Please provide your cc account info:• Username• Password

Pretend to be userPull statement

Expense system

Online statement

This seems wrong


RBH – step 1

RedirectAuthenticate locally (if needed)Express consent

(Authorization server)


RBH – step 2

Redirect back

Receive code

(callback address)

- User did not share passwd with app


RBH – step 3

Much better…

I can haz token?

Call API(with token)

- Application now accesses data on behalf of user

tmp code

access token


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


Social Login

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


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 [ ]



++token

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



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]

{ ‘sub’: ‘franco’, ‘email’: ‘[email protected]’…}user_info


Social Login -> OpenID Connect

API Provider -> IdP

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,…


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] […]

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

app


Nested handshakes

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

Do you authorize app* to get basic info about you?

Yes [x]No [ ]

app


Nested handshakes

Step 3User 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 [ ]

app


Nested handshakes

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

Two apps, two access tokens


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}


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


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 GrantGroup KeyChain

Mobile appsAPI Provider


Other ‘extension’ handshakes

Challenge-response grant– One-time passwords– Risk-based, context-based auth– Multi-factor

[Insert Secret] bearer grant– Cookie– …


Threats and Mitigation


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)

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

Do you authorize Legitimate app to access API on your behalf?

[X] Yes[ ] No

Tricked you


Fishing mitigation 101

Register and validate redirection URIs

Strict validation (not partial)

Never skip consent step

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

ErrorInvalid callback

foiled

(out-of-band)Register Legitimate appCallback=foo


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

http://developer.apple.com/library/ios/


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)


Client confidentiality does strengthen security

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

foiled

1. Compromised access tokens, refresh tokens

2. Exploit stolen token for x minutes

3. Token expired

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

5. Authentication required


Bearer vs MAC tokens

Bearer MAC

App developer

Tough choice

Adoption!


Bearer, use responsibly

App developerAPI PublisherOAuth Server Impl

- Don’t render them where they can be copied from.- Store them securely.- Server-side trust

- Don’t log them.- Forget original (hash them).

Bearer tokens are easier but need to be used responsibly– Exchanged and used over a secure channel

tokens in query strings


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)


Managing API Security

• Authorization Server• Policy Enforcement Point• Resource Server• ALFW• …

Decouple

Protect

Extend framework to

client app Integrate

• Web SSO• Analytics• Dev/User Portal• …

Configure, not code

Thank you

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

api security & federation patterns - francois lascelles, chief architect, layer 7 @ qcon sf

Technology