API adoption in both consumer and enterprises has gone beyond predictions. It has become the ‘coolest’ way of exposing business functionalities to the outside world. Both the public and private APIs, need to be protected, monitored and managed. API security has evolved a lot in last five years. The growth of standards, out there, has been exponential. Following best practices in securing APIs will help to wade through the weeds to keep the bad guys away while realizing the internal and external benefits of developing APIs for your services. This talk guides you through the maze of options and shares industry leading best practices in designing APIs for rock-solid security. Prabath Siriwardena, Director, Security Architecture at WSO2 presented this session at LASCON, Tx in October 2016.

1. API Security Best Practices
& Guidelines
Prabath Siriwardena, WSO2
@prabath on Twitter | prabath@wso2.com
API Security Best Practices
& Guidelines

2. About Me
● The Director of Security Architecture, WSO2
● Authored the book Advanced API Security - and three more

3. Managed APIs
● 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. Think About the Audience
● 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. Think About the Audience
● 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. Think About the Audience
● 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. Bootstrap Trust
● 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. Identify the Audience
● 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. Identify the Audience
● 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

10. OAuth 2.0

11. Authorization Code Grant Type

12. Implicit Grant Type (I)

13. Implicit Grant Type (II)

14. Client Credentials Grant Type

15. Password Grant Type

16. Federated Access to APIs
SAML Grant Type

17. Federated Access to APIs
JWT Grant Type

18. Federated Access to APIs
Self-Contained Access Tokens

19. Federated Access to APIs
Self-Issued Access Tokens

20. Chained APIs
Token Exchange

21. API Gateway Pattern

22. Fine-grained Access Control
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)
Security Considerations

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
Security Considerations