Securing Your API

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 Speciﬁcation 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 • Deﬁnes 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

Beneﬁts 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 • Deﬁned by the HTTP speciﬁcationThursday, 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 Workﬂow ?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 trafﬁc 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 trafﬁc requirementsThursday, May 26, 2011

Questions? Jason Austin - @jason_austin - jfaustin@gmail.com http://joind.in/3427Thursday, May 26, 2011

http://www.jasonawesome.com	681
http://feeds.feedburner.com	4
http://webcache.googleusercontent.com	1
http://html2canvas.hertzen.com	1

Securing Your API

by Jason Austin on May 26, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

4 Embeds 687

Statistics

Securing Your API — Presentation Transcript