How we achieved that without any external library
Auth0 is a popular identity and access management platform that provides developers an easy-to-use solution for securing their applications and APIs. With Auth0, developers can quickly add authentication and authorization to their applications without having to worry about the underlying infrastructure. Auth0 supports a wide range of authentication protocols and provides a customizable login page, multi-factor authentication, and social identity providers.
In this blog post, I will show the two possible solutions offered by the Auth0 SDK to log in the user, how migrating from one another could break your UI E2E automated tests, and how to “crack” a working solution to maintain your test checks all green ✅.
Auth0 makes authentication and authorization easy
Because you have better things to be worrying about.
And I couldn’t agree more, we developers have better things to spend our time on, login should always be an effortless implementation in an application, from all points.
In the specifics, the Android Auth0 SDK provides 2 ways of logging the user into your application:
Native login
The SDK provides a method to invoke to log in the user using a username and password. This method has variants, one accepting a callback, and one using coroutines, suspending the current thread.
Our app had already in place the native login, using callbacks (a bit of legacy code).
The method, inside the callback, provides you a Credentials object, containing both authToken and refreshToken, which you can then save using the CredentialManager class (from the Auth0 SDK), and re-access whenever you need them to perform any authorised-only API call to your backend.
This method is pure Java/Kotlin and requires you to set up your own UI (however you want) in your app.
Our app looked like this:
We had two fields: username and password, and a checkbox to keep the user logged in. The login button is disabled until both fields are filled with valid inputs.
Once the user clicks on the login button, we perform the login with Auth0 native authentication and then navigate the user accordingly to the correct page (either the dashboard or the account setup page).
WebAuth login
The WebAuth login instead, gives you a login page (that is customisable through the Auth0 dashboard), so you don’t have to think about the UI inside your app, not entirely, at least.
You just need to tell the SDK to start the web flow. We changed our login page to look like this
It is much simpler, it just has a login button and a checkbox to keep the user signed in. Once the user clicks on the login button, the web flow is started, and the webpage is shown:
To use the Auth0 SDK, some setup is required, and by some, I mean “very little”.
The shared setup between the WebAuth and Native is this simple line of code:
val account = Auth0("YOUR_CLIENT_ID}", "{YOUR_DOMAIN}")
With this, you will be able to log in the user with the WebAuth without anything else.
Native
For the Native login, some more configuration is needed:
val authentication = AuthenticationAPIClient(account)
With this authentication object, you can then login the user using the following code:
authentication.login(username, password).setScope(authScope).setAudience(authAudience).start(callback)
With:
authScopebeing the scope (configured on Auth0’s dashboard)
authAudiencebeing the audience (configured on Auth0’s dashboard)
and callbackbeing a Callback<CredentialsManager, AuthenticationException>used to proceed after the login is successful (gives back a Credentialsobject), or to show what went wrong from the AuthenticationExceptionreceived)
WebAuth
For the WebAuth instead, once you have the account object, you can directly call:
WebAuthProvider.login(account).withScope(authScope).withAudience(authAudience).start(activity, callback)
The parameters are the same as the ones above, with the addition of the activity (used to launch the new web activity with ACTION_VIEW from inside the SDK).
Some more configurations need to be done, as you have to specify the callback URLs (for login and logout) on the Auth0 dashboard, and inside your app. This can be done in the manifest as explained here.
Both
The code shown above allows you only to log in the user, and gives you back the Credentials. But if you don’t store and save them, you won’t be able to keep your user logged in or re-use them at will when needed.
To achieve this, some more code is needed:
val auth0Storage: SharedPreferencesStorage = SharedPreferencesStorage(context)
val credentialsManager: CredentialsManager = CredentialsManager(authentication, auth0Storage) // authentication is already defined above
Now with the credentialManager instance, you can save the credentials, using the fun saveCredentials(credentials: Credentials) function, and also retrieve them, using the function suspend fun awaitCredentials(): Credentials. You can also check, beforehand that the manager has valid credentials, using fun hasValidCredentials(): Boolean.
With these three functions, you will be able to log in the user, save his/her credentials, and retrieve them at will, whenever you need them.
Why migrate to WebAuth?
Since we started targeting a broader audience (we’re a B2B), some of our clients asked for — or suggested it would be nice to have — a universal login that allowed them to log in using existing accounts from other platforms (e.g.: Google, Microsoft, Apple, etc…). I won’t talk about all the UX processes that we went through, but in the end, it made sense, not requiring a personalised account on our side, and allowing a user to authenticate throughout another existing account would make ours — and their — lives easier.
Migration
As you might have already seen from the code above, the migration from one to the other is pretty easy and straightforward. There aren’t many differences, and both require a minimum effort to implement, even if starting from scratch.
In fact, it took a relatively short amount of time to do the migration, even using a TDD approach, refactoring all the tests first, and then applying the changes in the code to get back on a fully passing test (I’m talking about Unit tests here).
I left UI tests as the last thing to check and update and boy that was a mistake.
The changes on the clicks to be performed were easy, as it was removing all the “fill this field with X”.
The problem was now that, after tapping on the login button, we were outside of our codebase, outside of our application, in a WebView opened from an SDK of which we have no control.
We tried using Espresso Web with androidTestImplementation ‘androidx.test.espresso:espresso-web:3.4.0’ but unfortunately, the framework was not able to find the webview, probably because it was not inside any of our view hierarchies.
I asked the community on StackOverflow if anyone else faced the same problem before, hoping for an easy solution on how to interact with the WebView launched.
No luck.
So we tried checking if it was possible to configure, only for the test folder, the object WebAuthProvider to automatically perform the login for us, sending to it a username and password. I also opened a feature request on the Auth0 Android SDK here.
No luck. Again
We had to find another solution to keep our UI E2E tests running.
Interface to the rescue!
After struggling for a bit, we thought about using an interface to solve all our problems: the initial idea was WebAuthProvider required, and perform the login for us. This way, we could have two different implementations: one for our “real” codebase, the one that would run in production and allow the user to log in, and one that would be specific for testing, overriding the default implementation, and logging in the user without opening any webview or using the WebAuthProvider.
After considering what to provide this interface and what not, we came up with this solution:
interface WebAuthLogin {
fun login(activity: Activity,event: OpenUniversalLogin,onSuccess: ((result: Credentials) -> Unit), onFailure: ((error: AuthenticationException) -> Unit))
}where the OpenUniversalLogin event contains the following:
data class OpenUniversalLogin(val auth0: Auth0,val scheme: String,val scope: String,val audience: String,)Modules and test-substitution
With Hilt we were able to use dependency injection to configure correctly the scenarios listed above: 1 implementation for our production code,
Source link