Challenge in keeping Authentication Cookie on a remote server
Week 11 GSOC 2020 Final Coding Phase with AnitaB.org
It feels surreal. Two weeks to go and still quite a few things need to be done. Quite understandably I feel a bit nervous at the moment with the GSoC nearing the end. Today I’m going to share one of this week challenges which is keeping the session cookie for authentication on BridgeInTech remote server which is at the moment using the free Heroku web dyno.
Background
To explain the challenge, I’ll give you a brief information on the situation.
If you have been following my GSoC 20 journey, you would’ve already aware about the BridgeInTech (BIT) architecture that is using the React web application on the frontend and two REST APIs (BridgeInTech and Mentorship System (MS)) on the backend. Both REST APIs are connected to one database (here, the remote db is also using Heroku PostgreSQL). The database has two separate schemas, one which is specific to BridgeInTech whereas the other is specific to Mentorship System. Although it has two REST APIs, BridgeInTech user only make the request call to BridgeInTech REST API. For anything related to MS functionalities (such as Authentication, updating user personal details, and managing mentorship relations), BridgeInTech API will redirect user’s request to MS REST API which is then would return the relevant responses back to BridgeInTech API. At no point, BridgeInTech application is allowed to directly access the database to inspect the data inside the MS schema even though both BIT and MS are connected to the same database.
This might seem strange at first, but the benefits of having separate responsibilities to the specific schema are among the followings:
- to keep source data intact (one source of truth) which also makes it easier to troubleshoot bugs related to specific data.
- to minimize the impact of the changes made to one schema in case its database design is modified (such as by updating data format, adding/removing column in a table, etc).
- it also align to the Principle of Least Priviledge (POLP)
To know more about what is POLP or the other benefits, you can read these articles (article 1 and article 2)
You’ve learned about the background of this architecture. Now let's go to the problem.
Problem
Using the app architecture above, MS is in charge of Authentication (which it’s currently done using Flask JWT Extended. For any calls that require JWT token on MS REST API, BIT needs to pass this token on the HTTP request header before MS can process the request. At this stage in the development, BIT keeps the token returned by MS at login as a cookie. The issue is, this cookie is only kept for as long as the server is running or as long as the user logged in. As soon as the server is terminated/restarted or the user logout from the application, the cookie is automatically removed.
This sounds like nothing special, right. Sure thing, this works perfectly fine in a local environment where the developer have the full control of the BIT and MS local servers. However, when the application is deployed to Heroku, things start to get strange. The token seems to be unreliable with the responses randomly changes between the error 401 Unauthenticated with the customized message “Token is invalid” and a 200 Ok for a successful process, regardless that the same token was used in the request.
One potential suspect of this issue is the fact that BridgeInTech application is currently using the free dyno. Although a free dyno might be enough for a simple app, especially for one that is still on its early stage of development, in the case of BridgeInTech, this might pose as a blocker. The reason is because BridgeInTech has a lot of traffic than a usual simple app because BIT is constantly sending API calls to MS backend. Perhaps a bit too much for a free dyno to handle. To know more about the performance of this free Heroku web dyno, you can read it yourself here.
Another possible culprit of the inconsistent responses on the token cookie is the fact that the remote server is accessible to multiple users. Imagine this situation. User A logging in from location 1 and starts using the application by sending the token they received for the next requests. While user A is exploring the application, let’s say in location 2, user B also starts exploring this application and send login request to the remote server. If user B login is successful, the application will issue a new token as a response to B’s request and will replace user A cookie token with B’s token. User A, will then automatically be cut out from accessing the remote server without knowing why or how the token has suddenly become invalid.
Potential Solution
To be honest, I’m still looking for ways to solve this issue. If any of you reader out there have some advice on how to solve this situation, please do share it with me by commenting on this blog post. I’d really appreciate any input 😉.
At the moment, I have few things in mind on potential solutions. They are as follows:
- Upgrading the web dyno (pretty obvious, hey 😁). No need for extra explanation here, it’s pretty self-explanatory. More power == better performance.
- Sought out 3rd party authentication tools for both BIT and MS applications. As per the principle of POLP above, it is best to keep the authentication management on one hand. With 3rd party authentication tools, there is no need for BIT to keep authentication cookie in its backend server.
However, with the end of GSoC is nearing (this is the last week of the Final coding phase), I have to open for the possibility to push the solution to post GSoC and make do with using the BIT and MS local servers for my final GSoC presentation. 😌
Anyway, that’s it for today’s blog post. Later in the near future, I would share with you the solution to this issue if I found one (perhaps on the next and final blog? 🤞 🙏).
Until next time…
Profile Link:
