API Academy

Sponsored by Layer7

A city with many connected wires and lights.

Securing Microservices with API Management

By Balaji Radhakrishnan, PMP, CISSPPosted on

Today more and more enterprises are jumping into the bandwagon of digital transformation. To be competitive and aligned with this digital strategy, many enterprises started converting their monolithic and/or legacy applications into microservices to achieve:

  • Speed to market
  • Improve evolvability
  • Scalability
  • Enhance composability

API’s, which are the building blocks of digital transformation, have become the standard way of integration. As a result, API gateways have become a professed methodology in establishing secure communication with these microservices. API management provides the required security, access control, protection and service level management capabilities to OMNI channels (web, IoT, Mobile) that initiate the request.

API Management Deployment Architecture for Microservices

An API gateway can be deployed in the DMZ (external) intercepting an in-coming microservice request as an authentication hub in providing the required authentication/authorization service. Once properly authenticated, it could be routed to internal zone for further authorization, throttling and routing to specific backend services via lightweight micro gateways. Where enterprises can configure/deploy these micro gateways 1:1 ratio with corresponding backend applications (or Domain). This way API management not only provides the required security & access control but also decouples the backend services from a centralized API management strategy.

If you notice, with this deployment architecture, Edge Gateway acts as a client-side proxy and broker or service façade for microservices, where it orchestrates the microservices calls via corresponding micro gateways. Also, before routing the request, it applies required edge level security and besides, it can also bridge the security protocol with the required backend security solution.

Microservice Security End-to-End flow 

  1. Edge gateway should be able to:
  • Authenticate the Oauth2 bearer token
  • Authorize the request to the corresponding micro gateway based on the given scope.
  • Bridge the Oauth2 access token with relevant JWT by generate specific JWT token based on requested scope/audience and sign the payload. In some cases, the edge gateway may encrypt the JWT token as needed.

2. Micro gateway upon receiving the request:

  • Validate the JWT signature and claims as needed, this can be easily achieved via OpenID Connect APIs endpoint
    – well-known/openid-configuration
    – openid/connect/jwks.json
  • Authorize microservice request routing based on “scope†and/or “aud†claims in JWT payload
  • Throttle the request based on the application need and route the request to backend service with JWT header for further security validation by backend application as needed

Note: In this deployment architecture, the Edge Gateway will take care of North-South routing of the request to corresponding microservices. The enterprise should consider having service-mesh for any East-West routing within or between microservice-based applications to optimize network calls.

In this example above, I have used both Oauth2 Access token at the edge and JWT token RFC 7519 for the micro gateway but the same can be bridged with other security protocols as needed by microservice-based applications. Both the edge gateway and micro gateway along with backend applications, all should be mutually authenticated for secure communication. JWT is not session associated but by having a short lifespan (expiration) with encrypted/signed payload, we could mitigate the risk associated with Man-in-the-middle (MITM) attack.

Similarly, we could also leverage Oauth2 Mutual TLS RFC 8705 at edge gateway based on incoming channels (mobile, IoT), It is mentioned as “proof of possessionâ€. Where binding of access token with client certificate prevents stealing and unauthorized replay (more secure).
Finally, in an environment, where we have multiple resources (microservice applications), we could also leverage OAuth2.0 Resource Indicators RFC 8707, where the client needs to indicate what resource (microservice application) they intend the token to be used for.

Conclusion

With the growing app economy, there is an increased focus on digital transformation. And APIs are becoming a key enabler in establishing secure communication with Microservices. Layer7 API Management fulfills the demand of today’s enterprise in both securing and protecting their digital assets (microservices) with out of the box (OOTB) capabilities and features. 

As I have shown above, Layer7 API Gateway provides several such security protocols and integrates with a broad list of IAM systems and supports OAuth2/OpenID Connect, PCI-DSS, FHIR and PSD2. Layer7 API Gateway OOTB capable of bridging several security standards and solutions between consumers and providers.

If you don’t have Layer7 API Management, then you need to ensure your gateway provider provides similar supports to a wide range of security protocols and solutions along with comparable microservices (secured) integration options.