Securing Your API

Jason Austin - @jason_austin - jfaustin@gmail.com

Thursday, May 26, 2011

A Quick Rundown
API overview
API methodologies
Security methodologies
Best practices
Thursday, May 26, 2011

API vs. Web Service

API = Application Programming Interface
Web Service = API that operates over
HTTP

In this presentation, API == Web Service

Thursday, May 26, 2011

Why Create An API

Extend your product reach
Encourage mashups
Expose your data programmatically
Connect with developers
Thursday, May 26, 2011

API Success Stories

Twitter
Foursquare
Facebook

Thursday, May 26, 2011

Popular Methodologies

Thursday, May 26, 2011

REST
XML-RPC
SOAP

REST Service
Representational State Transfer
Architecture, not a standard
HTTP-based

Thursday, May 26, 2011

RESTful
Client-Server
Self-contained Requests (Stateless)
Cacheable
Named, Layered Resources
http://brewerydb.com/api/breweries/2324
http://brewerydb.com/api/beers/435

Thursday, May 26, 2011

REST over HTTP

GET - Read-only, for retrieving information
POST - Creating a new resource
PUT - Updating an existing resource
DELETE - Deleting an existing resource
Thursday, May 26, 2011

REST Security
None built in
Encryption over HTTPS
Left to the implementer
Error handling left to implementer
Thursday, May 26, 2011

SOAP Service
Simple Object Access Protocol
XML-based
Uses GET for read, POST for write
W3C Specification for sending and
receiving messages

Thursday, May 26, 2011

SOAP Security
Nothing provided in spec
WS-Security
Extension to SOAP spec
Provided as a guide for securing SOAP
services

Thursday, May 26, 2011

WS-Security
Guidelines for solving 3 problems
Identify and authenticate a client
Ensure integrity of the message
Curtail eavesdropping while in transit
Defines mechanisms as opposed to actual
protocols

Thursday, May 26, 2011

http://www.oasis-open.org/committees/wss/

XML-RPC Service
XML Remote Procedure Call
XML-based
Uses HTTP-POST
Spec published by UserLand Software in
~1998

Thursday, May 26, 2011

XML-RPC
Uses XML to specify a method and
parameters

Simple data structures, no objects

Arrays and Structs most complex

Thursday, May 26, 2011

XML-RPC Security
None in the spec
Encryption over HTTPS
Security left to the implementer
Error handling - <fault> base response
element

Thursday, May 26, 2011

Security Mechanisms

Thursday, May 26, 2011

OAuth
BasicAuth
API Keys

OAuth 1.0
Think of it as a valet key for
your internet accounts...
Open standard for API
access delegation
RFC 5849 - The OAuth 1.0
Protocol
Published April 2010

Thursday, May 26, 2011

OAuth 1.0 Players

Service Provider (Server)- Has the
information you want

Consumer (Client) - Wants the information

from the Service Provider

User (Resource Owner) - Can grant access

to the Consumer to acquire information
about your account from the Service
Provider

Thursday, May 26, 2011

Thursday, May 26, 2011

Benefits of OAuth 1.0

Applications dont need a users password
Power in the hands of the user
Secure handshake
Doesnt require SSL
Many libraries available
Thursday, May 26, 2011

OAuth 1.0 Pitfalls

Signatures based on complex cryptography
Server-side implementation is complex

Thursday, May 26, 2011

OAuth - Roll Your Own

Consumer Registration and Management
User pass-through, grant access
Consumer access management by User
Token storage and generation
2-legged vs. 3-legged
Thursday, May 26, 2011

OAuth 2.0 - Coming Soon

Removes signature requirement except on
token acquisition

Requires SSL
Single security token, no signature required
Guidelines for use with Javascript and
applications with no web browser

Thursday, May 26, 2011

More Info on OAuth

OAuth Spec
OAuth 2.0 Information
Lornas OAuth Blog Series
http://oauth.net/

http://oauth.net/2/

http://www.lornajane.net/

Thursday, May 26, 2011

BasicAuth

Passes a username and

password with the
request

Defined by the HTTP

specification

Thursday, May 26, 2011

BasicAuth Dos
SSL is a must
Username / Password is transmitted in
cleartext

Base64 encoded, but not encrypted

Basic > Digest

Basic assumes authentication is required
Digest requires extra transfer for nonce
Thursday, May 26, 2011

BasicAuth Pros
Client requests are easy
Part of nearly every HTTP request
library

Server setup is easy

Use existing BasicAuth credentials
Thursday, May 26, 2011

BasicAuth Cons
Requires a username and password for a
user

Credentials are not, by default, encrypted

Requires username and password to be
embedded in client code

Thursday, May 26, 2011

Access Keys

Not based on any

standard

Implementation
requirements are up to
the service provider

Keys -> signatures

Thursday, May 26, 2011

Access Key Basics

Part of URL
Sign request with key instead of passing it
http://pintlabs.com/api?key=23sdbk32

in URL

Use params + shared secret as signature

Thursday, May 26, 2011

Signed Request
Workflow
Client

?key=val

sign

?key=val&signature=23kcwej323

vje48hvn4

?key=val&signature=23kcwej323

Server

Thursday, May 26, 2011

?key=val

sign

vje48hvn4

23kcwej323

==

23kcwej323

Access Keys Pros

Easy to generate keys and distribute them
Typically removes the need to transfer
username and password in raw form

Signed requests prevents altering

parameters

Thursday, May 26, 2011

Access Keys Cons

Unsigned
Must embed them in code
SSL is not required, so will (by default)
transfer in plaintext

Signed
Encryption is scary....ish
Thursday, May 26, 2011

Best Practices for Keys

Use signed requests over unsigned
One key per application per developer
Require username in headers
Thursday, May 26, 2011

General Best Practices

Rate Limiting
Access Control
Error Handling
SSL Layer
API Domain
Stupid is as Stupid Does - Gump

Thursday, May 26, 2011

Rate-Limiting
Keeps API access in check
Authenticated and Unauthenticated calls
should be subject to rate limiting

Best practice
Have a standard, application wide rate
limit

Allow that limit to be overridden on a

per user, per application basis

Thursday, May 26, 2011

Rate-Limiting Best Practices

Authenticated
Have a standard, application wide rate
limit

Allow that limit to be overridden on a

per user, per application basis

Unauthenticated
Based on domain or IP address
Allow limit to be overridden as well
Thursday, May 26, 2011

Access Control
Treat API endpoints just as service
endpoints in your application

Have a standard API access site wide

Allow override on a per-user, perapplication basis.

Allows you to roll out features to a select

group or user

Thursday, May 26, 2011

Error Handling
Set appropriate HTTP headers
Provide viable, valid error messages
Log errors for the API too
Have a standard error response object for
all methods, including authentication

Thursday, May 26, 2011

SSL Layer
Encrypts all traffic to and from your API
Can cause performance hit
~10-15% in trials
Depending on protocol, should be a
requirement

Thursday, May 26, 2011

API Domain
Use sub-domain
Can move to separate webserver
Handle traffic requirements

Thursday, May 26, 2011

Questions?
Jason Austin - @jason_austin - jfaustin@gmail.com

http://joind.in/3427

Thursday, May 26, 2011