Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

API Security In Cloud Native Era

198 views

Published on

The cloud is rapidly becoming the de-facto standard for deploying enterprise applications. Microservices are at the core of building cloud-native applications due to its proven advantages such as granularity, cloud-native deployment, and scalability. With the exponential growth of the consumer base of these service offerings, enforcing microservice/API security has become one of the biggest challenges to overcome.

In this deck, we discuss:
- The need for API/Microservices Security
- The importance of delegating security enforcement to an API Gateway
- API Authentication and Authorization methodologies
- OAuth2 - The de-facto standard of API Authentication
- Protection against cyber attacks and anomalies
- Security aspects to consider when designing Single Page Applications (SPAs)

Watch the webinar on-demand here - https://wso2.com/library/webinars/2019/11/api-security-in-a-cloud-native-era/

Published in: Technology
  • Be the first to comment

  • Be the first to like this

API Security In Cloud Native Era

  1. 1. API Security in a Cloud Native Era Malintha Amarasinghe, Associate Technical Lead, WSO2 Thilini Shanika, Associate Technical Lead, WSO2
  2. 2. Cloud Native at a glance
  3. 3. Monolithic style vs Microservice style
  4. 4. Cloud Native Applications ● Comprised of a collection of loosely coupled lightweight microservices ○ Developed independently ○ Deployed independently ○ Scaled independently ● Decreased Time-To-Market ● Lower costs ● Extensibility and security
  5. 5. Challenges
  6. 6. Challenges in Securing Microservices ● Broader attack surface due to a large number of entry points ○ Security screening should be enforced at each endpoint level ● Performance ● Sharing user context ● Observability ○ Audit and application logging ○ Health check ○ Matrices ● Deployment complexities ○ Provisioning keys
  7. 7. Should we add a complex security stack over microservices themselves? ? A U T H A U T H A U T H A U T H
  8. 8. Should we add a complex security stack over microservices themselves? No A microservice: - performs one and only one business function - Do that one thing best !
  9. 9. API Gateway
  10. 10. ● Handling Security is delegated to API Gateway. ● Microservices can focus only about its business logic. ● Solves the multiple entry point problem. API Gateway
  11. 11. ● Responsible for three main functionalities in security PoV. ○ Authentication and Authorization ○ Protection against Malicious content ○ Abnormal pattern detection API Gateway
  12. 12. API Authentication and Authorization
  13. 13. ● APIs are mostly exposed for external users. ● Three parties are involved ○ API Creator ○ Application Creator ○ End User ● Access Delegation is important.
  14. 14. ● OAuth 2.0 is the defacto standard for API security ● Solves the requirement of Access Delegation when three parties are involved. ● Multiple grant types to support various use cases ○ password, client-credentials, authorization-code, .. ● Two types of tokens ○ Self contained access tokens (JWTs) ○ Reference Tokens (Opaque tokens) OAuth 2.0
  15. 15. ● Self contained access tokens (JWTs) ○ A JSON payload with header and signature sections ○ Signed using a shared secret or public/private key pair ○ Contains all the information required for validation ○ A better approach for microservice world Self Contained Access Tokens (JWTs)
  16. 16. Self Contained Access Tokens (JWTs)
  17. 17. Reference Tokens
  18. 18. • Password Grant – Simple to implement – Less secure – Can be used when Client and Authz Server belongs to the same entity. OAuth 2.0 - Grant Types
  19. 19. • Authorization Code – Authenticates the user at the Authorization Server. – User doesn’t pass the credentials to the Client Application – The Client Application can ensure that the access token will be not be exposed to any 3rd party (even the User Agent) – Suitable for traditional web applications OAuth 2.0 - Grant Types
  20. 20. Application (OAuth Client) OAuth Authorization Server 2 3 4 1 5 6 7 8 OAuth Resource Server Introspect Authenticate + Consent Authz Code 302 Access Token Rq (clientId + clientSecret + code) Access Token Access TokenAccess Token Resource Request Prerequisite Client application registered with the Authz Server manually or via Dynamic Client Registration Resource Owner Authorize Request (clientId)
  21. 21. • Single Page Apps (SPAs) and Mobile Apps are becoming increasingly popular. • Provide users with a rich and responsive user interface. • The common security mechanism in use: – Authorization Code with a public, untrusted client • Client authentication is not performed. • PKCE (Proof Key for Code Exchange) Securing Single Page Apps and Mobile Apps
  22. 22. • OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. Authorization Code with PKCE
  23. 23. Application (OAuth Client) OAuth Authorization Server 2 3 4 1 5 6 7 8 OAuth Resource Server Introspect Authenticate + Consent Authz Code 302 Access Token Rq (code + verifier) Access Token Access Token Access Token Resource Request Resource Owner Authorize Request (clientId + challenge + challenge_method)
  24. 24. • Client Credentials • Implicit • JWT Bearer Grant • SAML Bearer Grant OAuth 2.0 - Grant Types Contd..
  25. 25. OAuth 2.0 - Scopes ● Enable fine-grained access control to API resources ● Limit the amount of access granted for an access token ○ i.e: The scopes specifies what the Client Application can do on behalf of the end user.
  26. 26. Demo
  27. 27. Inventory Management System
  28. 28. Other Authentication Mechanisms .. • API Key – A secret token that only the API client and the server knows • Basic Authentication – Standard http Authorization header with base64 encoded username and password value Authorization: Basic base64-encoded(username:password)
  29. 29. Other Authentication Mechanisms .. ● Mutual TLS (Transport Level Security) ○ Service to service authentication in trusted channel
  30. 30. Open Policy Agent (OPA) ● A lightweight general-purpose policy engine that can be co-located with the service ● Can integrate OPA as a library, sidecar, or a host-level daemon
  31. 31. Propagating Trust And User Identity ● API backends might require authenticated user context for internal authentication and business functionalities ● The user context has to be passed from API gateway to backend, after the authentication process ● JWT tokens can be used to propagate – One’s identity – User entitlements, between interested parties
  32. 32. Malicious Contents
  33. 33. Protection Against Malicious Content • Regular expression threat protection ○ Injection attacks(SQL, Javascript, Java, xpath) • XML Schema validation ○ XML bombs ○ Schema poisoning ○ Coercive parsing ○ External entity attacks • JSON Schema validation ○ Coercive parsing ○ Buffer overflow
  34. 34. Abnormal Activity Patterns
  35. 35. Abnormal Activity Patterns • Account takeover with stolen credentials attacks • Login attacks • API takeover attacks • Data extraction or theft • Data scraping • Targeted API DDos attacks • Data deletion/manipulation • Data injection • Malicious code injection
  36. 36. Abnormal pattern detection by AI
  37. 37. Webinars to Follow ● November 19 - Cloud Native APIs: The API Operator for Kubernetes ● November 21 - Mine Your APIs for Gold: API Monetization ● December 03 - Beautifying the Beautiful: Theming WSO2 API Manager ● December 05 - Building a CI/CD Pipeline for APIs
  38. 38. Q & A
  39. 39. THANK YOU wso2.com

×