API Security Best Practices&

Guidelines

Prabath Siriwardena, WSO2Twitter: @prabath | Email: prabath@wso2.com

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

● 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

● 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

● 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

● 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

● 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

● 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

● 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

SAML Grant Type

JWT Grant Type

Self-Contained Access Tokens

Self-Issued Access Tokens

Token Exchange

XACML

● 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)

● 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