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/

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

12. API Authentication
and
Authorization

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

27. Inventory Management System

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

33. Malicious Contents

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

35. Abnormal Activity Patterns

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

40. THANK YOU
wso2.com