API Security Best Practices & Guidelines
6 likes2,860 views
This document provides API security best practices and guidelines. It discusses defining APIs and who may access them, such as employees, partners, customers or the general public. Authentication can be direct, using credentials, or brokered, using a third party. Best practices include using TLS, strong credentials, short-lived tokens, and throttling access. The guidelines aim to prevent attacks like CSRF, authorization code interception, and brute force attacks through measures like state parameters, PKCE, and long random tokens.
API Security Best Practices & Guidelines
- 1. API Security Best Practices & Guidelines Prabath Siriwardena, WSO2 Twitter: @prabath | Email: prabath@wso2.com
- 2. ● The Director of Security Architecture, WSO2 ● Authored the book Advanced API Security - and three more
- 3. ● The definition of the API has evolved over the time. ● It’s not just about the Application Programming Interface. ● Hosted, web-centric and public facing. ● Public facing does not always mean it’s outside your enterprise. ● Expose business functions to the rest of the world. ● Managed APIs ○ Secured ○ Monitored ○ Throttled
- 4. ● Who’s going to access your API and from where? ○ Employees, within the domain or outside the domain or both. ○ Partners ○ Suppliers ○ Customers ○ General Public
- 5. ● Is it a human or another system? ○ A user logs into a web app and the web app accesses an API on behalf of the end user. ○ Web app does not worry about the who the end user is when talking to an API
- 6. ● Who is having control over the system, which talks to the APIs ○ Mobile app talks to an API - the end user has the total control ○ Web app talks to an API the end user has no control ○ SPA talks to an API the end user has no control ○ Trusted clients / public clients
- 7. ● Direct Authentication ○ Trust the user directly - user could validate the trust by presenting a token known to the user and the service provider (API) both. ○ User credentials are under the control of the service provider. ○ Authenticate to Github API with username/password. ● Brokered Authentication ○ Do not trust each and individual users - but some entity who can assert a legitimate user to access the API. ○ User credentials are not under the control of the service provider. ○ The identity of the asserting entity can be validated by signature verification. ○ Login with Facebook
- 8. ● Direct Authentication ○ Username/password based authentication (basic auth) ○ OAuth 2.0 ■ Authorization server and the resource server under the same domain. ■ OAuth for authentication? ○ TLS mutual authentication ■ Trusts each certificate ○ JSON Web Token (JWT) ■ Self-issued JWT ○ Kerberos/NTLM ○ Custom API keys
- 9. ● Brokered Authentication ○ OAuth 2.0 ■ SAML 2.0 grant type ■ JWT grant type ■ …. ○ TLS mutual authentication ■ Trusts the issuer ○ JSON Web Token (JWT) ■ Trusts the issuer
- 16. SAML Grant Type
- 17. JWT Grant Type
- 20. Token Exchange
- 22. XACML
- 23. ● Use TLS in all the flows (bearer tokens) ● Store access tokens/refresh tokens/client credentials in a secure storage (at the client side) ● Store hashed access tokens/refresh tokens/client credentials in a secure storage (at the server side) ● Make sure access tokens/refresh tokens have the proper length to tolerate brute-force attacks. ○ The token value should be >=128 bits long and constructed from a cryptographically strong random or pseudo-random number sequence ● Use strong client credentials ○ Use short-lived assertions as the client_secret ● Use OAuth state parameter to tolerate CSRF attacks. ● Use scoped access tokens. ● Use PKCE to tolerate authorization code interception attacks (native mobile apps)
- 24. ● Enable throttling by user by application ● Use TLS token binding to tolerate token exports ● Restrict clients by grant types ● Avoid using the same client_id/client_secret for each instance of a mobile app - rather use the Dynamic Client Registration API to generate a key pair per instance. ● Short-lived access tokens ● Long-lived refresh tokens ● The token expiration time would depend on the following parameters. ○ risk associated with token leakage ○ duration of the underlying access grant ○ time required for an attacker to guess or produce a valid token ● One time access tokens (based on the use case) ● Client should validate the token audience