Securing Your API
Upcoming SlideShare
Loading in...5
×
 

Securing Your API

on

  • 11,766 views

Providing an Application Programming Interface (or API) has become a crucial piece of the modern web application. API’s provide opportunities to build the ecosystem around your application, opening ...

Providing an Application Programming Interface (or API) has become a crucial piece of the modern web application. API’s provide opportunities to build the ecosystem around your application, opening doors for collaboration and innovative mashups. However, the API opens up another entry point into your application, requiring that you somehow secure the access to it.

This talk will outline some of the options you have when securing your API. I’ll give overviews and implementation tips on some of the more popular schemes such as OAuth, HTTP authentication, and generating API keys. We’ll also look at some general API best practices such as rate limiting, error handling, and secure data communication.

Statistics

Views

Total Views
11,766
Views on SlideShare
10,254
Embed Views
1,512

Actions

Likes
8
Downloads
141
Comments
0

8 Embeds 1,512

http://www.jasonawesome.com 1495
http://feeds.feedburner.com 9
http://www.linkedin.com 2
https://www.linkedin.com 2
http://webcache.googleusercontent.com 1
http://html2canvas.hertzen.com 1
http://seoautomated.com 1
https://twitter.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Securing Your API Securing Your API Presentation Transcript

  • Securing Your API Jason Austin - @jason_austin - jfaustin@gmail.comThursday, May 26, 2011
  • A Quick Rundown • API overview • API methodologies • Security methodologies • Best practicesThursday, May 26, 2011
  • API vs. Web Service • API = Application Programming Interface • Web Service = API that operates over HTTP • In this presentation, API == Web ServiceThursday, May 26, 2011
  • Why Create An API • Extend your product reach • Encourage mashups • Expose your data programmatically • Connect with developersThursday, May 26, 2011
  • API Success Stories • Twitter • Foursquare • FacebookThursday, May 26, 2011
  • Popular Methodologies • REST • XML-RPC • SOAPThursday, May 26, 2011
  • REST Service • Representational State Transfer • Architecture, not a standard • HTTP-basedThursday, 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/435Thursday, 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 resourceThursday, May 26, 2011
  • REST Security • None built in • Encryption over HTTPS • Left to the implementer • Error handling left to implementerThursday, May 26, 2011
  • SOAP Service • Simple Object Access Protocol • XML-based • Uses GET for read, POST for write • W3C Specification for sending and receiving messagesThursday, May 26, 2011
  • SOAP Security • Nothing provided in spec • WS-Security • Extension to SOAP spec • Provided as a guide for securing SOAP servicesThursday, 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 • http://www.oasis-open.org/committees/wss/Thursday, May 26, 2011
  • XML-RPC Service • XML Remote Procedure Call • XML-based • Uses HTTP-POST • Spec published by UserLand Software in ~1998Thursday, May 26, 2011
  • XML-RPC • Uses XML to specify a method and parameters • Simple data structures, no objects • Arrays and Structs most complexThursday, May 26, 2011
  • XML-RPC Security • None in the spec • Encryption over HTTPS • Security left to the implementer • Error handling - <fault> base response elementThursday, May 26, 2011
  • Security Mechanisms • OAuth • BasicAuth • API KeysThursday, May 26, 2011
  • 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 2010Thursday, 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 ProviderThursday, May 26, 2011
  • Thursday, May 26, 2011
  • 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 availableThursday, May 26, 2011
  • OAuth 1.0 Pitfalls • Signatures based on complex cryptography • Server-side implementation is complexThursday, 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-leggedThursday, 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 browserThursday, May 26, 2011
  • More Info on OAuth • OAuth Spec http://oauth.net/ • OAuth 2.0 Information http://oauth.net/2/ • Lorna’s OAuth Blog Series http://www.lornajane.net/Thursday, May 26, 2011
  • BasicAuth • Passes a username and password with the request • Defined by the HTTP specificationThursday, May 26, 2011
  • 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 nonceThursday, May 26, 2011
  • BasicAuth Pros • Client requests are easy • Part of nearly every HTTP request library • Server setup is easy • Use existing BasicAuth credentialsThursday, 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 codeThursday, May 26, 2011
  • Access Keys • Not based on any standard • Implementation requirements are up to the service provider • Keys -> signaturesThursday, May 26, 2011
  • Access Key Basics • Part of URL http://pintlabs.com/api?key=23sdbk32 • Sign request with key instead of passing it in URL • Use params + shared secret as signatureThursday, May 26, 2011
  • Signed Request Workflow ?key=val Client sign ?key=val&signature=23kcwej323 vje48hvn4 ?key=val&signature=23kcwej323 Server ?key=val sign vje48hvn4 23kcwej323 == 23kcwej323Thursday, May 26, 2011
  • 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 parametersThursday, 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....ishThursday, May 26, 2011
  • Best Practices for Keys • Use signed requests over unsigned • One key per application per developer • Require username in headersThursday, May 26, 2011
  • General Best Practices • Rate Limiting • Access Control • Error Handling • SSL Layer • API Domain “Stupid is as Stupid Does” - GumpThursday, 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 basisThursday, 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 wellThursday, 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, per- application basis. • Allows you to roll out features to a select group or userThursday, 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 authenticationThursday, 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 requirementThursday, May 26, 2011
  • API Domain • Use sub-domain • Can move to separate webserver • Handle traffic requirementsThursday, May 26, 2011
  • Questions? Jason Austin - @jason_austin - jfaustin@gmail.com http://joind.in/3427Thursday, May 26, 2011