Multi-tenant SDK Authentication

  • Google Pay app may have SDK from ICICI Bank, HDFC Bank, and SBI Bank.
  • Ola app may have SDK from Google Maps, Weather Channel, and ICICI Bank.
  • Zeta Benefits Wallet app may have RBL Cards SDK, CCAvenue Payment Gateway SDK, Razorpay Payment Gateway SDK, Stripe SDK, etc.

Why not conventional mechanisms?

In the conventional OAuth flows the App Provider is treated as a client of the User of each publisher and authorization is provided to the App Provider to access resources corresponding to the User.

  1. Establish identity with App Providers.
  2. Forward that identity established in step 1 to Publisher1 in a reliable way.
  3. Publisher1 verifies the forwarded identity and grants access to the user as Identity@Publisher1
  4. Forward that identity established in step 1 to the Publisher2 in a reliable way.
  5. Publisher2 verifies the forwarded identity and grants access to the user as Identity@Publisher2.

Setup an Authentication mechanism for the SDK

Zeta’s entire SDK range uses the above authentication mechanism through the Apollo App Center. Different teams when working on their respective mobile SDKs use the Apollo App Center to publish and distribute their SDKs. The consumers of these SDKs, for example. Fintechs, Neobanks, and VBOs can sign-up for the SDKs through the Apollo App Center. We are continuously working towards extending support for different banks and financial institutions to publish their own SDKs on the Apollo App Center.

  • Memory optimization
  • Multi-modality

Resource crunch

As mentioned above, we might have a situation where we want to integrate multiple SDKs hosted on the Apollo App Center. Since we already have the authentication module built, the first thought that comes to our mind is to create multiple instances of authentication objects, one per SDK. This is resource taxing and non-scalable. Zeta is continuously building newer SDKs to cater to client requirements. With each new SDK, we instantiate new objects that could be highly unoptimized for resource-constrained mobile devices.

Enter REST mobile modules!

We want all modules we build to start acting as small microservices following the REST principle of statelessness. The idea is to pass the information needed by the module as parameters, in the context of an API call, instead of passing them as initialization parameters. This helps us in avoiding the creation of multiple instances for the same class.

Multi-modality of authentication modules

Different SDKs need different authentication mechanisms to make authenticated API calls. Let’s say that the Cards SDK is making a simple REST API call to generate authentication tokens. On the other hand, the Payment SDK uses an authenticated socket connection to make the API call. With this requirement in mind, the authentication module now supports different types of authentication clients.

Conclusion

In this article,

  1. We have discussed the challenges in authenticating different SDKs in the banking domain.
  2. We discussed the Apollo App Center as a marketplace for the SDK publishers and consumers.
  3. We also discussed the solution for authenticating SDKs and the client implementation for the same for the mobile platforms.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
'Celebration of Engineering'

'Celebration of Engineering'

Engineering adventures and the stories from the trenches