securing your api
Post on 17-Oct-2014
11.693 Views
Preview:
DESCRIPTION
TRANSCRIPT
Securing Your API Jason Austin - @jason_austin - jfaustin@gmail.com
Thursday, May 26, 2011
• API overview
• API methodologies
• Security methodologies
• Best practices
A Quick Rundown
Thursday, May 26, 2011
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
Why Create An API
• Extend your product reach
• Encourage mashups
• Expose your data programmatically
• Connect with developers
Thursday, May 26, 2011
API Success Stories
• Foursquare
Thursday, May 26, 2011
Popular Methodologies
• REST
• XML-RPC
• SOAP
Thursday, May 26, 2011
REST Service
• Representational State Transfer
• Architecture, not a standard
• HTTP-based
Thursday, May 26, 2011
• Client-Server
• Self-contained Requests (Stateless)
• Cacheable
• Named, Layered Resourceshttp://brewerydb.com/api/breweries/2324http://brewerydb.com/api/beers/435
RESTful
Thursday, 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 resource
Thursday, May 26, 2011
REST Security
• None built in
• Encryption over HTTPS
• Left to the implementer
• Error handling left to implementer
Thursday, May 26, 2011
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
SOAP Security
• Nothing provided in spec
• WS-Security
• Extension to SOAP spec
• Provided as a guide for securing SOAP services
Thursday, 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 ~1998
Thursday, May 26, 2011
• Uses XML to specify a method and parameters
• Simple data structures, no objects
• Arrays and Structs most complex
XML-RPC
Thursday, May 26, 2011
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
Security Mechanisms
• OAuth
• BasicAuth
• API Keys
Thursday, 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 2010
Thursday, 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 Provider
Thursday, 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 available
Thursday, May 26, 2011
OAuth 1.0 Pitfalls
• Signatures based on complex cryptography
• Server-side implementation is complex
Thursday, May 26, 2011
• 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
Thursday, May 26, 2011
• 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
Thursday, May 26, 2011
More Info on OAuth
• OAuth Spechttp://oauth.net/
• OAuth 2.0 Informationhttp://oauth.net/2/
• Lorna’s OAuth Blog Serieshttp://www.lornajane.net/
Thursday, May 26, 2011
BasicAuth
• Passes a username and password with the request
• Defined by the HTTP specification
Thursday, 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 nonce
Thursday, May 26, 2011
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
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
Access Keys
• Not based on any standard
• Implementation requirements are up to the service provider
• Keys -> signatures
Thursday, May 26, 2011
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
Thursday, May 26, 2011
Signed Request Workflow
?key=val
vje48hvn4
sign ?key=val&signature=23kcwej323Client
?key=val vje48hvn4sign
?key=val&signature=23kcwej323
23kcwej323 23kcwej323==
Server
Thursday, 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 parameters
Thursday, 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....ish
Thursday, May 26, 2011
• Use signed requests over unsigned
• One key per application per developer
• Require username in headers
Best Practices for Keys
Thursday, May 26, 2011
• Rate Limiting
• Access Control
• Error Handling
• SSL Layer
• API Domain“Stupid is as Stupid Does” - Gump
General Best Practices
Thursday, 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 basis
Thursday, May 26, 2011
• 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
Thursday, 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 user
Thursday, 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 authentication
Thursday, 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 requirement
Thursday, May 26, 2011
API Domain
• Use sub-domain
• Can move to separate webserver
• Handle traffic requirements
Thursday, May 26, 2011
Questions?Jason Austin - @jason_austin - jfaustin@gmail.com
http://joind.in/3427
Thursday, May 26, 2011
top related