Securing Your API
•
26 likes•17,842 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 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.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Securing Your API
Similar to Securing Your API (20)
More from Jason Austin
More from Jason Austin (11)
Recently uploaded
Recently uploaded (20)
Securing Your API
- 1. Securing Your API Jason Austin - @jason_austin - jfaustin@gmail.com Thursday, May 26, 2011
- 2. A Quick Rundown • API overview • API methodologies • Security methodologies • Best practices Thursday, May 26, 2011
- 3. 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
- 4. Why Create An API • Extend your product reach • Encourage mashups • Expose your data programmatically • Connect with developers Thursday, May 26, 2011
- 5. API Success Stories • Twitter • Foursquare • Facebook Thursday, May 26, 2011
- 6. Popular Methodologies • REST • XML-RPC • SOAP Thursday, May 26, 2011
- 7. REST Service • Representational State Transfer • Architecture, not a standard • HTTP-based Thursday, May 26, 2011
- 8. 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
- 9. 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
- 10. REST Security • None built in • Encryption over HTTPS • Left to the implementer • Error handling left to implementer Thursday, May 26, 2011
- 11. 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
- 12. SOAP Security • Nothing provided in spec • WS-Security • Extension to SOAP spec • Provided as a guide for securing SOAP services Thursday, May 26, 2011
- 13. 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
- 14. XML-RPC Service • XML Remote Procedure Call • XML-based • Uses HTTP-POST • Spec published by UserLand Software in ~1998 Thursday, May 26, 2011
- 15. XML-RPC • Uses XML to specify a method and parameters • Simple data structures, no objects • Arrays and Structs most complex Thursday, May 26, 2011
- 16. 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
- 17. Security Mechanisms • OAuth • BasicAuth • API Keys Thursday, May 26, 2011
- 18. 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
- 19. 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
- 20. Thursday, May 26, 2011
- 21. 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 Thursday, May 26, 2011
- 22. OAuth 1.0 Pitfalls • Signatures based on complex cryptography • Server-side implementation is complex Thursday, May 26, 2011
- 23. 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
- 24. 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
- 25. 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
- 26. BasicAuth • Passes a username and password with the request • Defined by the HTTP specification Thursday, May 26, 2011
- 27. 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 Thursday, May 26, 2011
- 28. 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
- 29. 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
- 30. Access Keys • Not based on any standard • Implementation requirements are up to the service provider • Keys -> signatures Thursday, May 26, 2011
- 31. 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 signature Thursday, May 26, 2011
- 32. Signed Request Workflow ?key=val Client sign ?key=val&signature=23kcwej323 vje48hvn4 ?key=val&signature=23kcwej323 Server ?key=val sign vje48hvn4 23kcwej323 == 23kcwej323 Thursday, May 26, 2011
- 33. 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
- 34. 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
- 35. Best Practices for Keys • Use signed requests over unsigned • One key per application per developer • Require username in headers Thursday, May 26, 2011
- 36. General Best Practices • Rate Limiting • Access Control • Error Handling • SSL Layer • API Domain “Stupid is as Stupid Does” - Gump Thursday, May 26, 2011
- 37. 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
- 38. 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
- 39. 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 Thursday, May 26, 2011
- 40. 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
- 41. 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
- 42. API Domain • Use sub-domain • Can move to separate webserver • Handle traffic requirements Thursday, May 26, 2011
- 43. Questions? Jason Austin - @jason_austin - jfaustin@gmail.com http://joind.in/3427 Thursday, May 26, 2011