API Security Best Practices& Guidelines

Prabath Siriwardena, WSO2@prabath on Twitter | prabath@wso2.com

API Security Best Practices& Guidelines

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

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

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

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

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

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

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

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

OAuth 2.0

Authorization Code Grant Type

Implicit Grant Type (I)

Implicit Grant Type (II)

Client Credentials Grant Type

Password Grant Type

Federated Access to APIsSAML Grant Type

Federated Access to APIsJWT Grant Type

Federated Access to APIsSelf-Contained Access Tokens

Federated Access to APIsSelf-Issued Access Tokens

Chained APIsToken Exchange

API Gateway Pattern

Fine-grained Access ControlXACML

● 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

● 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