Architecture: Asgardeo Android Core Auth Direct SDK for native app authentication | by Achintha Isuru

Asgardeo Android Core Auth Direct SDK Development Journey — Episode 3

Hello everyone, I’m back to continue our development journey of the new Asgardeo Android Core Auth Direct SDK. To recap, in Episode 1 we performed our concurrent analysis of similar SDKs. In the next episode, we discussed learnings from competitor analysis and how we plan to implement our SDK. If you haven’t read the previous episodes, you can find them here:

Episode 1: A Deep Dive into Mobile SDKs for Native App Authentication: A Competitor Analysis

Episode 2: Basics: Lessons from Competitor Analysis

In today’s episode, I’ll detail the full architecture of the Asgardeo Android Core Auth Direct SDK that we’re building on this journey.

Before diving into the architecture, it helps to have a basic understanding of native application authentication. If you’re not familiar with native app authentication, you can find more details in our first episode.

The following diagram illustrates the high-level steps involved in native application authentication. So consider the following example and scenario:

1. When the user clicks the login button, the application calls the /authorize endpoint, which returns the authenticators related to the first step [STEPS 1,2,3].
2. If the user decides to authenticate with a username and password, the application will call the /authn endpoint and pass the username and password, continuing until there are no more authentication steps [STEPS 4,5,6].
3. Finally, the necessary tokens can also be collected by redeeming the authorization code [STEPS 7].

Unlike the typical OIDC flow, where the user is redirected to a browser window, this new application-native authentication occurs via REST APIs.

Hopefully, you now have a good understanding of the inner workings of native Asgardeo app authentication. If you would like to learn more about native app authentication, you can do so by clicking this link.

Now that we understand the inner workings of native app authentication, let’s take a look at the architecture of the Asgardeo Android Core Auth Direct SDK.

The image above represents the large-scale architecture of the Asgardeo Android Core Auth Direct SDK. This SDK can be divided into four main layers:

1. Provider layer
2. Main configuration layer
3. Middle layer
4. Data layer

Let’s look at each of these layers separately.

Provider layer

This layer has all the functions necessary for an Android developer to integrate native app authentication into their Android application. As the diagram shows, the provider layer consists of three main components:

1. Authentication Provider
2. Token Provider
3. Supplier Managers

Authentication and token providers have wrapper functions that call functions in a provider manager, which then calls functions implemented in the backend layer.

The authentication provider exposes the functionality needed for native application authentication, such as initializeAuthentication(), authenticateWithUsernameAndPassword()And disconnect(). The token provider exposes functionality for managing tokens, such as getAccessToken() And validateAccessToken().

Provider handlers have handler classes that call functions in the core layer. For example, the User Provider Manager calls functions related to obtaining user information.

Main configuration layer

When using the SDK, the developer can either use the discovery endpoint or add all the necessary endpoints such as authorization and token endpoints. This layer defines SDK configurations based on data provided by the developer. If the developer has grabbed their Asgardeo organization’s discovery endpoint, this layer will call it, fetch all the necessary endpoints, and set them accordingly.

Middle layer

This layer contains all the implementations and this is where the magic happens in the SDK. It consists of three elements:

1. Authentication core
2. Native authentication manager core
3. Managers

Authentication Core and Native Authentication Handler Core are wrapper classes for functions implemented in handlers. The provider layer interacts with these main classes without knowing the implementation details, which are encapsulated in the handlers.

The Authentication Core class contains wrapper functions for functions related to native application authentication. Additionally, the SDK provides functionality to directly call native authentication APIs, such as Google’s Credential Manager API. The Native Authentication Handler Core encompasses these native functions, implemented in native authentication handler handlers.

Managers manage the specific actions of the unit; for example, the User Manager handles API calls related to obtaining user information from Asgardeo. If you look closely at the managers component of the core layer, you will see a manager called AppAuth Manager, which is responsible for calling the Android AppAuth SDK, to manage the lifecycle of the token. Since this SDK already has this logic implemented, we chose to use it directly in our SDK instead of reinventing the wheel.

Data layer

The last layer of the SDK is the data layer. This layer is responsible for storing and retrieving token information in the phone’s memory. To store data, this SDK uses the datastore library provided by Android. This layer allows developers to skip the login interface when a user returns to their app and already has a valid token.

Why so many layers?

Now that you better understand the architecture of the Asgardeo Android Core Auth Direct SDK, you may be wondering why there are so many layers in the Asgardeo Android Core Auth Direct SDK. The reason is to increase the maintainability of the SDK. By having multiple layers, higher layers, such as the provider layer, are abstracted from implementation details. This separation allows us to change the implementation without affecting the developer’s code, ensuring a more robust and flexible SDK.

In this episode, we explored the architecture of the new Asgardeo Android Core Auth Direct SDK and briefly reviewed the inner workings of native Asgardeo app authentication. We also discussed the rationale for multi-layer architecture. If you found this article interesting, share it with your colleagues and stay tuned for our next installment in this development journey.