My Hustle-bustle with the full-stack development
Tags: codenewbie, mobile, beginners
Published: 2020-12-18 20:50:40

Hello Devs!    

I am going to write about my first ever full-stack app development story today. There are lots of things going on with me right now and I want to be honest about my experience so far. Anyone can glorify or gloss over their failure, however, I believe knowing my weakness and making mistakes is the best way to learn as a code newbie.

What can you learn from reading this?
You may gain general ideas about the development and a better insight before you start building an application or if you were considering developing a mobile application using Expo and Auth0, this would be a straightforward answer for your decision. My bottom line is that I am carrying lots of technical debts as a result of my lack of experience and expertise throughout the mobile application development.

Moreover, I am not a Java, Kotlin nor Swift developer. You may have noticed that if you have ever read my blogs before. I am a JavaScript developer who started learning JS with my enthusiasm for web development and naturally learned React Native. To develop a fully functional native application on your own, I think you are either a seasoned native developer or a 10x ninja full stack developer(or a walking tech company). But, I'm proud of my failure and happy to see myself improving. :-)

---

I have encountered the most nail-biting and tiring issue with the authorisation in conjunction with using the framework “Expo” and Auth0 since I started coding.

The main reason I chose Expo is the same reason why many developers chose frameworks over native languages; It provides many benefits such as an easy configuration, ample dependencies which can substitute the native functionalities without actually using the native language, Java/Kotlin(for Android) and the developer community which can be useful when I face any issues during the development. Since Expo has a fairly big community for React Native developers, I thought it would be the right choice.

My goal was to implement the authorisation code flow with PKCE(Proof Key for Code Exchange; called Pixy) which is the standard authentication method for the modern native applications and SPA(single page application)s. I initially wanted to add the minimum security layer on the backend for the databases which would be storing users' financial data. I underestimated the implication of the Pixy due to lack of my understanding. Even though this is not a commercial application, I wanted to simulate a real personal finance application-like feeling. I naively presumed that this wouldn't be much different from Role-based access control management. However, I have encountered two considerable impediments during the implementation of authorisation.


![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/8y6ryn8lsqkhiak70o5p.jpg)

### Discordance of the two tech stacks, Expo and Auth0

I spent loads of time and effort trying to make the two tech stacks work, this was the most devious and dubious path I have gone through as a developer. As I only have a limited experience with Auth0 and I have seen a React Native example from its website, I made a hasty decision without knowing the implication in the practicality of the implementation.

For any newbie developers who are still reading this far, let me explain to you about the Pixy first. An OAuth authorisation request should be performed through an external user-agent(such as the web browser) for the best practice in native applications and it also enables single sign-on for a better user experience.

I am not a security expert, but, simply put, would an embedded user-agent be used, the app would retain valuable data, such as users’ credentials and OAuth authorisation grant. Those can be obtained by hackers or an imitated fraudulent application and it will be detrimental for all the users of the application. The best practice for calling APIs from a native application is to implement the Pixy.

**Unfortunately, with much self-doubt as a limited-experienced developer, I was convinced that I was doing something incorrectly, but was not sure what was missing.**

The `managed flow` with Expo which was initially chosen by me, hoping for a manageable development experience, provides its proxy server `exp://auth.expo.io/@user_name/app_name` which mitigates carrying a heavy load such as, the creation of a proxy server to deal with the redirect URI in order to receive the authorisation code from Auth0’s Authorisation server. 

To receive the authorisation code from the server, the client app should send `code_challenge`, `code_verifier` and `state` to the server. I created all of them using Expo libraries such as expo-crypto, expo-random and some JavaScript codes. Expo offers the ‘AuthSession’ API to deal with authentication and authorisation. All I needed was to retrieve the authorisation code from the authorisation server. 

I tried most methods, class and examples which were provided by Expo and what other online blogger suggested. But, it was just all in vain. For some reasons, I couldn’t get the code as the Auth0 and Expo documentation state. This was the loophole of my authorisation experience as a developer. 

During that time, I discovered that my codes worked on a web browser(on the condition that I assigned the localhost on the login callback URL in Auth0 configuration and the browser returned the authorisation code successfully). This puzzled me and I started blaming Expo as it didn’t return the code only on the emulators. I also found other developers, from online forums, who alleged that AuthSession API seemed to be broken after a few updates and those claims convinced me that AuthSession was the issue. 

I eventually have even spoken to the Expo developers after I tagged `@expo` on my twit. The developer I spoke to advised me kindly even though it was a Saturday evening. As I spoke to him, I kept trying what he suggested. Unfortunately, it didn’t work again. I was so frustrated, it was beyond any description. But, it led me to the final clue why it didn’t work on the emulators. 

Auth0 requires the extra `Login URI` to be specified on its configuration page only for some native applications. This wasn’t clear throughout my development. There weren't enough resources about it. Moreover, because the `Auth0 Login URI scheme` must start with `https://`, it convinced me that Auth0 and Expo cannot be compatible since the Expo proxy server scheme is `expo://`. This is not all, though. 

### Auth0 doesn’t support JavaScript for the native application

The long story, in short, Auth0 doesn’t fully support JavaScript for the native applications. I should've known this. Until I found an Auth0’s engineer’s reply from its repository after a lot of research, I wasted too much time figuring out what was causing the issue without knowing it. This apparently becomes a technical debt for my assessment. 

If it is a commercial project, I would advise you to contact the authentication platform you have chosen to discuss the practicality and trade-offs before you make a firm decision or if you are in a team, you may already have an authentication expert. 

My first challenge to develop a native application on my own has not been a great success. However, you cannot achieve true success without failures.