API Security & Oauth Patterns RSA Europe @flascelles

Session ID: STAR-305Session Classification:

Intermediate

Francois LascellesLayer 7 Technologies

Enterprise Access Control Patterns for

REST and Web API

Today’s enterprise API drivers

enterprise boundary

distributed enterprise SOA

• Sensitive data, apps• Mission critical• ID authority• Legacy

partner

SAAS

mobile

IAAS/PAAS

developer

Integration APIs!

B2B

APIs!

B2C

APIs!

Cloud APIs!

Access control?

Agenda

WS-* web services have rich security standards and authentication/authorization mechanisms

Web API, RESTful web services tend to use proprietary tokens, point-to-point solutions

What are the common patterns in use? Which standards are emerging? How to use specialized infrastructure to

implement access control? How to accommodate requesting party

technical capabilities?

Pattern 1: API Keys in URI parameters

Simplest thing, common practice Shared secret in a URL parameter based

authentication, no signature involved Equivalent to

https://host/api/resource?username=franco&password=mysecret

Why not use HTTP Basic instead?

https://host/api/resource?keyid=foo&keysecret=bar…

Pattern 2: HMAC

5

PUT /api/resource…Authorization: AWS keyid:fr0t5AzM6qT3S40pBPmfrTLJwMuZurA8=…

Use the key to actually sign something Shared secret not sent Payload covered by signature -> message

integrity Timestamp covered by signature -> less

susceptible to replay Used by AWS, Azure Implementations are proprietary, not

compatible

Pattern 3: OAuth

Autz server

Application

Resource owner

Do something with my resource

Yes, I authorize it

Retrieve resource with owner authorization(REST exchange)

GET /somewhere/someresource…Authorization: OAUTH fr0t5AzM6qT3S40pBPmfrTLJwMuZurA8=…

Resource provider

OAuth Benefits

OAuth 2.0 is poised to fill the standards gap Passwords remain secret Tokens easier to ‘control’ than passwords Resource-oriented => perfect for REST Many different flows to accommodate

different use cases (two and three parties) Different token types

Bearer (easy, like cookies) MAC (integrity, more secure)

What about SAML?

A rich and established standard for making various claims regarding an identity (authentication statements, authorizations statements, attribute statements) SAML is well supported by existing enterprise

infrastructure SAML is verbose

8KB is too big a token for an authorization header or a query parameter

You can gzip + base 64 encode the token to make it fit SAML is based on XML

My API uses JSON, not XML It does not matter, the two should be decoupled

Binding specifications for Web browser SSO, SOAP+WSS, but no formal binding for REST, web APIs SAML Bearer Profile for OAuth 2.0

Sample SAML binding for RESTful web service

9

GET /token/joeAuthorization: …

200 OK<saml:Assertion …/>

GET /someresourceAuthorization: SAML PmfrTLJwMuZurA8=

200 OK…

trust

10

Step-by-step enterprise API access control

(from an OAuth perspective)

Starting Point

Resource owner

Resources (API)

OAuth Client(application)

enterprise/provider admin

I needmore OAuth

FAIL!

OAuth Clients Provisioning, Management

app developer

provider admin

1. Create/manage my account, get shared secret, define my callback

2. Approve new clients, list existing client, get stats on usage

3. Provision app with account id, shared secret

2

1

3

OAuth Clients

Runtime Policy Modeling, Integration

OAuth Clients

1. Administrator declares internal APIs to be accessed using OAuth authorization

a) which token types – Bearer, Macb) which flowsc) http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-

03

Prot Res Server

1

1

1

OAuth Handshake

OAuth Clients

1. Client redirect owner to oauth provider2. Policy looked up, flow executed:

OAuth handshake as per flow. 3. Client is authenticated, gets access

token

3 OAuth Autz server

2

OAuth Tokens

22, 3 2, 3

1Prot Res Server

OAuth Resource Retrieval

OAuth Clients

1. Client uses access token to access resource2. Protected resource server validates incoming token, authorize

specific access based on token attributes, updates usage statistics

3. The API is called on behalf of, and returned to client

OAuth Tokens

Prot Res ServerOAuth Autz server

1

2

3

Token Refresh

OAuth Clients

1. Client uses refresh token to extend access resources on behalf of resource owner. Autz server authenticates Client and update the token

2. Client access resource using refreshed token

OAuth Tokens

OAuth Autz server

Prot Res Server1

11

2

2

2

Owner-driven Token Revocation

OAuth Clients

1. Resource owner revokes authorization previously granted to Client. Autz server revokes corresponding token.

2. Client tries to access resource, access is refused.

OAuth Tokens

OAuth Autz server

Prot Res Server

2

1

1

FAIL!2

Provider-driven Token Revocation

OAuth Clients

1. Client is hacked, access tokens compromised

2. Administrator revokes all tokens issued to this particular client

3. Hacker cannot use old tokens to access resources

OAuth Tokens

OAuth Autz server

Prot Res Server

3

2

FAIL!1

4. Client prompts resource owner to repeat OAuth handshake. Owner does not need to change password.

3

Monitoring, Reporting

OAuth Clients

1. Report on APIs, Clients, Owners. Monitor usage, performance.

OAuth Tokens

OAuth Autz server

Prot Res ServerAnalytics

Comprehensive REST Access Control

OAuth ClientsProvisioningApproval FlowPersistenceQueryingMetrics

OAuth TokensPersistenceQueryingMetricsRevocationRefresh

OAuth Autz serverPolicy ModelingOAuth ProtocolIdentity integrationToken issuingToken refreshSLA enforcement

Prot Res ServerPolicy ModelingToken validationBearer, MACIdentity integration, SAMLIntegrity checkAPI proxyingSLA enforcement

AnalyticsReportsMonitoringSLAsAlerting

*all of this*

Omg, it’s full of win

APPLY

Decouple OAuth and other access control mechanisms from actual API implementations

Enable OAuth for existing APIs by deploying OAuth broker at perimeter Configure, not code

Ensure support for OAuth 2.0 and all of its richness

21

22

Thank you

For more information:info@layer7.com