POSTS

API Access Security in Digital Transformation Stack

- 4 minutes read - 703 words

Attacks and data violations involving poorly secured APIs are occurring regularly. Protecting web APIs with general-purpose application security solutions alone continues to be ineffective. Each new API represents an additional and potentially unique attack vector into your systems. Modern application architecture trends — including mobile access, microservice design patterns, and hybrid on-premises/cloud usage has driven security to have largely a single “gateway” point at which protection can be enforced (Frankly, if you can’t govern that then you are at the helm of bigger problem).

Based on typical digital transformation architecture public layers like experience APIs are the most vulnerable. Other layers have attack vectors too but given they are not exposed to the internet it can be managed with good network security practices like these.

Exp Layer typically sits with API gateway solutions which have come up a long way to provide that single layer which can block any threat vector. While API security has many aspects like throttling, rate limiting, message security etc. the primary focus of this blog is identity and access.

Access control is the number-one security driver for API Gateway technology, serving as a governor of sorts so an organization can manage who can access an API and establish rules around how data requests are handled. An API Gateway’s access control capabilities usually start with authentication mechanisms to determine the actual source of any API calls. Currently, the most popular framework is OAuth 2.0, which acts as an intermediary for accessing web-based resources. And the other auth (authorization) is handled by the popular JWTs.

Cloud-native API gateway solutions offer OAuth based integration natively as you can see below for GCP and AWS. https://cloud.google.com/endpoints/docs/openapi/authenticating-users-firebase https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-integrate-with-cognito.html

But I am going to talk about a custom solution as many enterprise systems like to have control of the features on identity and access of the APIs and can meet the pace of their product development. Below is the high level view of the architecture.

auth

Typical Flow for the client API request is:

  1. Any channel creates an HTTPS request to a secured API including auth bearer token which is a JWT or a payload including credentials if login/registration (which includes anonymous/application credentials based JWT). If it’s present, the user will be allowed to access protected resources and the request is intercepted by exp API auth function or policy
  2. Policy forwards the request to authorization MS decrypts, validates, and elicit info from JWT signed token payload. Which can only be done by the verified signatory. The role-based access is also certified based on the payload. This helps implement the stateless authorization.
  3. The extracted access token is verified by the authentication MS (which is backed by an IDP).
  4. Once confirmed the other extracted private headers like customer data etc. are added to the original request.
  5. Access is granted to other microservices or APIs which are part of the ecosystem and required secured information from the JWT payload.

For the graphQL based exp API, we can create the reusable resolver function which goes against the authentication and authorization microservices as below.

graphql-auth

Oauth Grants to be used with this architecture

Implicit: A grant which trusts the client and gives them access without the 3 legged authentication. This should be implemented for the clients which are regulated by the enterprise.

Auth-code: A grant which requires server-side validation to add additional security over clients that are not controlled by the enterprise. Third-party integrations are good examples of this pattern.

PKCE: This pattern is used for untrusted devices like mobile apps, web apps or handheld devices.

Conclusion

I have tried to cover the landscape of how this architecture can help with the API security but by no means this is a comprehensive guide. The reliability, resiliency, and scalability of this architecture is equally important along with building the right OAuth grant flow and applying business logic to provide the right API access to a client or a user. Also, I have made an assumption here that Authentication MS is backed by an IDP bur that’s not a hard-fast rule and can be a custom in house solution to compliment the authorization service.

Connect with Me

If you are interested for a conversation or a chat. Please reach me on my linkedin.