Apollo App Center is a marketplace for SDKs. Each SDK can be published by different publishers. Each publisher has its own identifiers for its users.

A few examples:

• 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.

In all of the above cases, the app hosting the SDKs wants to integrate various services from third parties using the SDKs provided by those parties to provide increased functionality to its users. But each of those SDKs represents isolated services from that of the parent app and the user of the app could be using those services from various other interfaces outside the purview of the parent app or parent app provider.

Thus, the identity domains and thereby the authentication domains of the app and the included SDKs are different. Unless there is some federation of identity and authentication, the user of the app has to establish their identity using potentially different authentication mechanisms of each SDK. For example, a Zeta Benefits Wallet user may have to log in several times within the app to access services provided by different SDKs. An Ola app user would have a similar experience.

The objective of the authentication federation approach is to avoid the need for each SDK publisher to authenticate the user separately.

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.

In sensitive domains such as banking and payments, the user resources cannot be accessed by any third-party service provider. The Publisher ensures only the end-user is accessing the resources using the SDKs provided by the publisher.

Therefore, although the SDKs are embedded by the app provider, the app provider themselves are not acting as a client of the user. Thus, a conventional OAuth approach to federate identities from publisher to app provider is not possible.

The solution implemented federates the identity provided by the App Provider and the Publisher is made the relying party. The publisher may rely on the identity and credentials provided by the app provider as is, depending on the reliability of the app provider’s authentication, or may offer additional challenges to the user before granting access to the service.

Shown below is the Authentication Flow.

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.

In the above diagram, you can see that there is a single instance of the authentication module object in memory. The consumer of the authentication module passes the authentication context as part of the API call.

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.

All the SDKs can now tell the authentication module the type of authentication clients they want to use. In the diagram below, you can see that Cards SDK makes a request to initialize its auth context by generating an auth token with an HTTP API call; whereas the Payment SDK needs a separate socket connection, which in itself would be authenticated.

Here is a short code snippet showing how simple it is to specify the authentication client inside the SDK.

if(useWebSocket) { ApolloUserauthmanagerCompFactory.init(ApollouseWebSocketAuthSessionComponentFactory.getInstance().authSessionClient())
} else { ApolloUserauthmanagerCompFactory.init(ApolloRestAuthSessionClientFactory.getInstance().authSessionClient())
}

Any requests generated from the Payment SDK can then be directly made through this channel. The WebSocket channel gives additional capabilities to listen to the push messages from the server and helps in building a true reactive behavior on the client-side.

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.

Thank You