API Security In Cloud Native Era
2 likes•569 views
The document discusses the security challenges of microservices in cloud-native applications, highlighting the broader attack surface and the need for security at every endpoint. It emphasizes the role of an API gateway in managing authentication, authorization, and protecting against malicious content, with OAuth 2.0 being the recommended standard for API security. Various authentication mechanisms and grant types are reviewed, underscoring the importance of handling user context and protecting against threats such as injection attacks and abnormal activity patterns.
API Security In Cloud Native Era
- 1. API Security in a Cloud Native Era Malintha Amarasinghe, Associate Technical Lead, WSO2 Thilini Shanika, Associate Technical Lead, WSO2
- 2. Cloud Native at a glance
- 3. Monolithic style vs Microservice style
- 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. Challenges
- 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. 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. 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. API Gateway
- 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. ● Responsible for three main functionalities in security PoV. ○ Authentication and Authorization ○ Protection against Malicious content ○ Abnormal pattern detection API Gateway
- 13. ● APIs are mostly exposed for external users. ● Three parties are involved ○ API Creator ○ Application Creator ○ End User ● Access Delegation is important.
- 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. ● 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. Self Contained Access Tokens (JWTs)
- 17. Reference Tokens
- 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. • 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. 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. • 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. • OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. Authorization Code with PKCE
- 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. • Client Credentials • Implicit • JWT Bearer Grant • SAML Bearer Grant OAuth 2.0 - Grant Types Contd..
- 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. Demo
- 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. Other Authentication Mechanisms .. ● Mutual TLS (Transport Level Security) ○ Service to service authentication in trusted channel
- 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. 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
- 34. 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
- 36. 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
- 37. Abnormal pattern detection by AI
- 38. 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
- 39. Q & A