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.
Tata AIG General Insurance Company - Insurer Innovation Award 2024
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
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
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
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