Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
API Security Best Practices
& Guidelines
Prabath Siriwardena, WSO2
@prabath on Twitter | prabath@wso2.com
API Security Bes...
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 Inte...
Think About the Audience
● Who’s going to access your API and from where?
○ Employees, within the domain or outside the do...
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 o...
Think About the Audience
● Who is having control over the system, which talks to the APIs
○ Mobile app talks to an API - t...
Bootstrap Trust
● Direct Authentication
○ Trust the user directly - user could validate the trust by presenting
a token kn...
Identify the Audience
● Direct Authentication
○ Username/password based authentication (basic auth)
○ OAuth 2.0
■ Authoriz...
Identify the Audience
● Brokered Authentication
○ OAuth 2.0
■ SAML 2.0 grant type
■ JWT grant type
■ ….
○ TLS mutual authe...
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 APIs
SAML Grant Type
Federated Access to APIs
JWT Grant Type
Federated Access to APIs
Self-Contained Access Tokens
Federated Access to APIs
Self-Issued Access Tokens
Chained APIs
Token Exchange
API Gateway Pattern
Fine-grained Access Control
XACML
● Use TLS in all the flows (bearer tokens)
● Store access tokens/refresh tokens/client credentials in a secure
storage (at...
● Enable throttling by user by application
● Use TLS token binding to tolerate token exports
● Restrict clients by grant t...
API Security Best Practices & Guidelines
Prochain SlideShare
Chargement dans…5
×

API Security Best Practices & Guidelines

1 517 vues

Publié le

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.

Publié dans : Technologie
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

API Security Best Practices & Guidelines

  1. 1. API Security Best Practices & Guidelines Prabath Siriwardena, WSO2 @prabath on Twitter | prabath@wso2.com API Security Best Practices & Guidelines
  2. 2. About Me ● The Director of Security Architecture, WSO2 ● Authored the book Advanced API Security - and three more
  3. 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. 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. 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. 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. 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. 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. 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. 10. OAuth 2.0
  11. 11. Authorization Code Grant Type
  12. 12. Implicit Grant Type (I)
  13. 13. Implicit Grant Type (II)
  14. 14. Client Credentials Grant Type
  15. 15. Password Grant Type
  16. 16. Federated Access to APIs SAML Grant Type
  17. 17. Federated Access to APIs JWT Grant Type
  18. 18. Federated Access to APIs Self-Contained Access Tokens
  19. 19. Federated Access to APIs Self-Issued Access Tokens
  20. 20. Chained APIs Token Exchange
  21. 21. API Gateway Pattern
  22. 22. Fine-grained Access Control XACML
  23. 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. 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

×