The problem NFT Auth solves

The Problem

Authentication is one of the core elements of any system that wants only a subset of the audience to be let in. It could be a creator who wants to let only those have a sneek-peek into their bts clips who are their hardcore fans; it could be a closed community which allows only selected individuals and within them, only allows certain members to have edit access. In short, in the web3 realm, it could be any system that allows only the holders of their NFTs to be let in. As of now, there is no standard on authenticating based on NFT ownership. Without a standard, there is no fixed set of rules which every party adheres to while implementing NFT-based authentication.

The Solution

My project is a 3-fold solution.

Protocol

First is the protocol-development part. It covers developing a protocol for NFT-based authentication. It is more theoretical where I attempt to clearly lay down the theoretical aspects of the protocol and how it would enable a third-party application to obtain limited access to an HTTP service on behalf of a resource owner by orchestrating an approval interaction among the resource owner, the cryptocurrency wallet that they own and the HTTP service.

SDK

Second is the development of an SDK which facilitates the NFT-based authentication and is inline with the protocol-development part. To begin with, I chose Node.js to develop the SDK. The code would be open source and configurable as per the requirements of the product which wishes to implement the NFT-based Authentication. There would be a backend and a frontend code as samples demonstrating how to integrate the SDK. The SDK would make life easier for any web3 product looking to implement NFT-based authentication.

NAPA

Third is the development of NAPAs(NFT Auth Powered Applications) based on market research. I have developed an MVP for a streaming solution (Owncast-X) which uses NFT as auth layer and lets selected users to access the special content/streaming of a streamer.

Challenges I ran into

NPM package challenge

This was my first time deploying an npm package on the npm registry. The nature of the SDK is of being stateful, i.e. it has to maintain its state during the entire lifecycle of the product which integrated it (for e.g it has to remember the initial configuration with which the product initialized it with, in order to generate the access tokens and verify them). I could see that writing an npm package which is just a utility and that does not require to maintain its state is pretty straight-forward; you just need to write a plain JS function. For my requirement, writing a class seemed to be the natural choice but for some reason, the resulting npm package was not behaving in the intended manner. I could not spend time verifying if npm packages are supposed to be a set of functions only (seems unlikely though). So, I got around it by refactoring the class as a higher-order function.

CORS challenge

Note: The apps mentioned in this para are just sample and tbh, not fun. Owncast-X is the real deal (check video).
I intended to use free services to host a sample webapp demonstrating the NFT-auth SDK. My sample backend is deployed at https://testiflqnwk.herokuapp.com/ but the frontend is deployed at https://authnft-js.vercel.app/. For security reasons, browsers restrict cross-origin HTTP requests. The solution is to configure CORS properly. It was a challenging task because 1) I did not configure CORS for such environment before, 2) the online forums are mostly filled with solutions which are either outdated (Chrome kept on putting/increasing restrictions in the cross-origin requests realm) or suited for AWS/GCP/Azure, 3) too many CORS headers to configure correctly. After a series of trial-and-error, I was finally able to configure everything properly and my webapp was fully functional.

Integration with Owncast

To build Owncast-X, I needed to make changes to the codebase of Owncast. Understanding and compiling owncast had some hiccups.