Securing APIs
2 likes1,225 views
The document discusses authentication methods for APIs, including basic authentication, OAuth, and different OAuth token and signature types like bearer tokens and MAC signatures. It notes some limitations of basic authentication and outlines the OAuth handshake process. It then compares bearer tokens, which allow access by any party possessing the token, to MAC signatures, which require demonstrating possession of a cryptographic key.
Securing APIs
- 1. Prabath Siriwardena Senior Architect & Chair, Integration MC Johann Nallathamby Software Engineer, Integration MC
- 4. AWS Signature -‐ 1 • Split the query string based on '&' and '=' characters into a series of key-‐value pairs. • Sort the pairs based on the keys. • Append the keys and values together, in order, to construct one big string (key1 + value1 + key2 + value2 + ... ). • Sign that string using HMAC-‐SHA1 and your secret access key.
- 5. AWS Signature -‐ 2 • You include additional components of the request in the string to sign • You include the query string control parameters (the equals signs and ampersands) in the string to sign • You sort the query string parameters using byte ordering • You URL encode the query string parameters and their values before signing the request • You can use HMAC-‐SHA256 when you sign the request (we prefer HMAC-‐SHA256, but we still support HMAC-‐SHA1) • You must set the SignatureMethod request parameter to either HmacSHA256 or HmacSHA1 to indicate which signing method you're using • You must set the SignatureVersion request parameter to 2
- 9. Third-‐party applications are required to store the resource owner's credentials for future use, typically a password in clear-‐ text.
- 10. Servers are required to support password authentication, despite the security weaknesses created by passwords.
- 11. Third-‐party applications gain overly broad access to the resource owner's protected resources, leaving resource owners without any ability to restrict duration or access to a limited subset of resources.
- 12. Resource owners cannot revoke access to an individual third-‐ party without revoking access to all third-‐parties, and must do so by changing their password.
- 13. Compromise of any third-‐party application results in compromise of the end-‐user's password and all of the data protected by that password.
- 23. • Complexity in validating and generating signatures. • No clear separation between Resource Server and Authorization Server. • Browser based re-‐redirections.
- 25. BasicAuth OAuth Handshake
- 27. Runtime
- 28. Bearer MAC Runtime
- 29. Bearer MAC Bearer Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). Runtime
- 30. Request with Bearer GET /resource/1 HTTP/1.1 Host: example.com Authorization: Bearer “access_token_value” http://tools.ietf.org/html/draft-‐ietf-‐oauth-‐v2-‐bearer-‐20 Runtime
- 31. Bearer MAC MAC HTTP MAC access authentication scheme Runtime
- 32. Request with MAC GET /resource/1 HTTP/1.1 Host: example.com Authorization: MAC id="h480djs93hd8", ts="1336363200" nonce="274312:dj83hs9s", mac="kDZvddkndxvhGRXZhvuDjEWhGeE=" http://tools.ietf.org/html/draft-‐ietf-‐oauth-‐v2-‐http-‐mac-‐01 Runtime