securing your api

Securing Your API Jason Austin - @jason_austin - [email protected]

Thursday, May 26, 2011

mailto:[email protected]


• API overview

• API methodologies

• Security methodologies

• Best practices

A Quick Rundown


API vs. Web Service

• API = Application Programming Interface

• Web Service = API that operates over HTTP

• In this presentation, API == Web Service


Why Create An API

• Extend your product reach

• Encourage mashups

• Expose your data programmatically

• Connect with developers


API Success Stories

• Twitter

• Foursquare

• Facebook


Popular Methodologies

• REST

• XML-RPC

• SOAP


REST Service

• Representational State Transfer

• Architecture, not a standard

• HTTP-based


• Client-Server

• Self-contained Requests (Stateless)

• Cacheable

• Named, Layered Resourceshttp://brewerydb.com/api/breweries/2324http://brewerydb.com/api/beers/435

RESTful


http://brewerydb.com/api/beers/435

http://brewerydb.com/api/beers/435

REST over HTTP

• GET - Read-only, for retrieving information

• POST - Creating a new resource

• PUT - Updating an existing resource

• DELETE - Deleting an existing resource


REST Security

• None built in

• Encryption over HTTPS

• Left to the implementer

• Error handling left to implementer


SOAP Service

• Simple Object Access Protocol

• XML-based

• Uses GET for read, POST for write

• W3C Specification for sending and receiving messages


SOAP Security

• Nothing provided in spec

• WS-Security

• Extension to SOAP spec

• Provided as a guide for securing SOAP services


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

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


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

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


• Uses XML to specify a method and parameters

• Simple data structures, no objects

• Arrays and Structs most complex

XML-RPC


XML-RPC Security

• None in the spec

• Encryption over HTTPS

• Security left to the implementer

• Error handling - <fault> base response element


Security Mechanisms

• 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


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


Benefits of OAuth 1.0

• Applications don’t need a user’s password

• Power in the hands of the user

• Secure handshake

• Doesn’t require SSL

• Many libraries available


OAuth 1.0 Pitfalls

• Signatures based on complex cryptography

• Server-side implementation is complex


• Consumer Registration and Management

• User pass-through, grant access

• Consumer access management by User

• Token storage and generation

• 2-legged vs. 3-legged

OAuth - Roll Your Own


• 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

OAuth 2.0 - Coming Soon


More Info on OAuth

• OAuth Spechttp://oauth.net/

• OAuth 2.0 Informationhttp://oauth.net/2/

• Lorna’s OAuth Blog Serieshttp://www.lornajane.net/


http://www.lornajane.net




BasicAuth

• Passes a username and password with the request

• Defined by the HTTP specification


BasicAuth Do’s

• 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


BasicAuth Pros

• Client requests are easy

• Part of nearly every HTTP request library

• Server setup is easy

• Use existing BasicAuth credentials


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


Access Keys

• Not based on any standard

• Implementation requirements are up to the service provider

• Keys -> signatures


Access Key Basics

• Part of URLhttp://pintlabs.com/api?key=23sdbk32

• Sign request with key instead of passing it in URL

• Use params + shared secret as signature


http://pintlabs.com/api?key=23sdbk32

http://pintlabs.com/api?key=23sdbk32

Signed Request Workflow

?key=val

vje48hvn4

sign ?key=val&signature=23kcwej323Client

?key=val vje48hvn4sign

?key=val&signature=23kcwej323

23kcwej323 23kcwej323==

Server


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


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


• Use signed requests over unsigned

• One key per application per developer

• Require username in headers

Best Practices for Keys


• Rate Limiting

• Access Control

• Error Handling

• SSL Layer

• API Domain“Stupid is as Stupid Does” - Gump

General Best Practices


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


• 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

Rate-Limiting Best Practices


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, per-application basis.

• Allows you to roll out features to a select group or user


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


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


API Domain

• Use sub-domain

• Can move to separate webserver

• Handle traffic requirements


Questions?Jason Austin - @jason_austin - [email protected]

http://joind.in/3427






securing your api

Technology