This is a submission for the Permit.io Authorization Challenge: API-First Authorization Reimagined
What I Built
My intention with this project is to have a different approach to create Role Games in Javascript (or any other language in the front side, like Python, Lua, even Unity), I made a set or roles and resources based on a simple definition of elements, in this case a super basic role game with 4 different characters (Elf, Wizard, Warrior, Dwarf), each character has its abilities, weapons, curses, etc.
This approach isolates the logic of abilities, weapons, and other stuff for each character from the game logic. If I want to change a character's abilities, I only need to go to Permit IO Interface and change the policies, which will be reflected directly in the game without touching the game code.
The API returns the list of Resources (abilities, weapons, armor, etc) and players (roles in Permit IO).
The free version of Permit IO doesn't allow me to create resourceTypes using the SDK (nodejs). I tried this approach that could be implemented in the full version, allowing the application to be more dynamic, avoiding using Permit IO UI.
Finally, I made a backend using Express and NodeJS, frontend using React/Tailwind/DaisyUI to show the data.
Demo
Project Repo
Repo: Permit Hackaton
My Journey
I like to organize logic into layers, and my approach to this project was based on that principle. I began by researching different ways to integrate Permit.io and decided to try something unique by applying its authorization logic to a role-playing game (RPG) configurator, since I enjoy creating video games.
Initially, I encountered problems when attempting to use ES Modules in Node.js. Each time I enabled "type": "module" and utilized import statements, the Permit.io library would fail. After investing almost six hours trying to fix it, I ultimately reverted to the require method—a more conventional CommonJS approach, which functioned reliably.
Second, when finally my backend worked, I built a Node.js API and tested a few basic calls following Permit.io’s documentation. Once I had a working prototype, I explored more advanced ideas, such as dynamically creating resources and policies. Unfortunately, that part didn’t work as expected, so I reviewed the latest version of the Permit.io API to troubleshoot and adapt.
Third, I created a screen that displays players along with their roles and access permissions. These settings will later be reflected directly in the gameplay, forming the foundation for role-based interactions in the RPG.
Fourth, I created the frontend using React/Typescript/Tailwind/Vite to provide a good option for showing the resources, players, and configurations. Only the admins can change elements in this interface. Permit IO and Clerk (to manage User Login and JWT) also manage this logic, which works well with Permit IO.
API-First Authorization
Based on the number of characters in my game, I added four Roles, each Role represents a character in my game.
These roles have different rules, the rules are related to the items (an item can be an ability, a weapon, a magic, a curse, etc). These items are saved in Permit IO as a Resources.
All this configuration is possible using the SDK via my Backend. With my UI connected to those services, I'm calling different functions to create roles and assign permissions to them.
You can find this functionality in two sections: create character and create actions.
This approach gives me much flexibility if I need to change each character's abilities, weapons, etc. without touching my frontend/backend code, which is perfect when I need to manage separation of concerns.
I created a middleware in my backend to verify the access via Permit IO, using permit.check.
I get the Resources using permit.api.resources.list()
I get the Players using permit.api.roles.list()
I create new Players from the UI using permit.api.roles.create()
I create new items and actions for a player using permit.api.updateRole
