Using Hanko with Permit.io

This guide will show you how to add an easily manageable authorization layer on top of your Hanko implementation, providing you with a simple way to determine what users can access within the application after logging in.

Although this application code is built with Next.js, Permit.io provides SDKs for any common language, So this example can give you a good idea of how it should look in your language.

Note that this tutorial is meant to be used on an application with Hanko authentication already set up.

We highly recommend cloning our demo application so you can follow the steps more easily.

If you prefer to read the article without cloning the application, skip this section and continue to Setup Basic Role Based Authorization.

To clone the demo application, run the following commands:

1. Clone the application

   git clone <[e-mail]>:permitio/permit-hanko.git
   
2. Install the dependencies:

   npm install 
   
3. Run the application:

   npm run dev
   

   At this point, the application will fail to run as we need to set up the Hanko and Permit services.

Setting up Hanko Passkey Authentication:

1. Setup your Hanko Webapp

   Visit the Hanko webapp, create a new organization (Or use your existing one), and give it the name you want.

2. Create a new project

   In the main dashboard, create a new project - assign http://localhost:3000 as the App URL.

3. Copy API URL

   From the Settings > General section of the project, copy the API URL.

4. Paste API URL

   Paste the API URL to a new file called .env.local, in the root directory of the application. When we run the application again, we can see that the error is gone, and we can see the login page.Now, when we run the application again, we can see that the error is gone, and we can see the login page.

5. Add the authentication window

   To add this authentication window, use the Hanko SDK for JavaScript. You can see the element that implemented the login flow in the app/auth/login/page.tsx file.

   <Paper sx={{ p: 2 }}>
     <HankoAuth />
   </Paper>
   
6. Redirection Logic

   We added the following middleware logic to the middleware.ts file that redirects the user to the login page if they are not authenticated:

   const authenticateUser = async (req: NextRequest): Promise<string> => {
   if (!hankoApiUrl) {
   return "";
   }
   // Get Hanko token from cookie
   const hanko = req.cookies.get("hanko")?.value;
   
    ...
   
   // Authenticate user using Hanko
   const user = await authenticateUser(req);
   // Redirect to login page if user is not authenticated
   if (!user) {
   urlToRedirect.pathname = LOGIN_URL;
   return NextResponse.rewrite(urlToRedirect);
   }
   

   With the authentication configuration and flow configured, we are ready to continue with the implementation of Permit.io for authorization in our application.

Setup Basic Role Based Authorization

With authentication done, it is time to set up our authorization layer. We’ll start with setting up basic role-based access control (RBAC) to determine the actions our users can perform.

In the /app/api/notes/route.ts, you’ll find four functions, GET, POST, PUT, and DELETE - responsible for the logic of getting, creating, updating, and deleting notes, respectively.

If you look at the route.ts file, you will see that we are going to use a generic permit.check middleware.ts file.

const response = await fetch(`${pdpUrl}/allowed`, {
    method: "POST",
    headers: {
        Authorization: `Bearer ${permitApiKey}`,
        "Content-Type": "application/json",
        Accept: "application/json",
},
body: JSON.stringify({
    user: user,
    action,
    resource: resource,
    context: {},
    }),
});

This code is a generic permit.check function that checks the permissions configured for the application using three factors:

User - the entity that attempts to perform the operation (in our case, a user authenticated with Hanko).

Action - the operation that the user will attempt to perform (in our case, GET).

Resource - the entity that the user will attempt to perform the operation on (in our case, the note).

At this point, we haven’t configured the Permit SDK key in the app, so any user can perform any operation. Setting up a Permit.io account will fix this.

Now, we must configure these permissions in Permit.io. Note that we can adapt them to our needs without having to change any of the application code!

1. Create a Permit.io account

   Go to app.permit.io, Create an account, set up a new organization, and give it whichever name you want.

2. Create Roles

   In the left sidebar, click on Policy, then go to the Roles tab, and create the following roles: Admin and User.

   
3. Create Resources and Actions

   In the Resources tab, create a new resource called notes, with the following four actions and an owner attribute: get, post, delete, and put.

   
4. Setup Permissions

   Back in the Policy tab, let’s allow all users to get and post notes, and only admins to put, and delete notes.

   
5. Setup API Credentials

   To copy your API key, click your user profile in the top right of the screen, and click Copy SDK API Key. Add the key in your in the env.local file:

   PERMIT_API_KEY=<YOUR_COPIED_API_KEY>
   
6. Configure the API endpoint

   We will also need to configure the Permit.io API endpoint to check the permissions. For this purpose, we will use the Permit cloud service.

   PERMIT_PDP_URL=[https://cloudpdp.api.permit.io](https://cloudpdp.api.permit.io)
   

To make sure all environment variables are in place, restart the application.

Now that we have everything set up within Permit.io, it is time to sign up with a user and test if it works.

Sync Hanko Users to Permit.io

To check the permissions we configured, we need to sync the users from Hanko to Permit.io, so our users will be known to the Permit policy engine.

We will want to automatically assign a user role to every new user, so they will also be part of our newly configured policy. This role helps us to keep the principle of least privilege and give new users only very basic permissions in the application.

In the demo application, you can find the following code in the src/app/api/permit/route.ts file:

const response = await permit.api.syncUser({

key,
  email,
  attributes: {
    roles: ["user"],
  },
});

await permit.api.roleAssignments.assign({

role: "user",
  tenant: "default",
  user: key,

});

This code, as you can see, syncs the user to Permit.io if they do not exist yet.

Check the Permissions

1. Login with a user

   In the localhost:3000 page, log in with a user of your choice, and make sure you have the right passkey configured.

2. Create a new note

   Create a new note on the first screen of the application. It should appear on the list.

3. Check the Audit Logs

   In the Permit.io Dashboard, go to the Audit Log tab in the left sidebar. You should see that the post action was logged. Clicking the log will allow you to see detailed information about the authorization decision that allowed for this action to be performed. Allow will equal true as this user has the User role.

   
4. See the permissions in action!

   If we try to delete the note, we will get an error message saying we are not allowed to access this resource. If we grant an Admin role to this user via Permit.io’s UI, the error will be resolved and we will be able to delete the note.

   

Now that we are done with the Role Based model in our application let’s go to the next phase and make our permissions more fine-grained

Add Fine-Grained Attribute-Based Authorization

For this section to run properly, you need to run the Permit.io PDP as a sidecar. You can read how to do that here.

As stated before, the delete action in our app is supposed to be limited to the same user who created the role. This is a more complex policy that cannot be defined by using simple roles - it needs attributes as well.

We can configure this policy in Permit and see it take effect immediately in the application.

1. Enable ABAC in Permit Dashboard

   Navigate to the Policy page, select ABAC Rules, and activate the ABAC option.

   
2. Define Resource Set Rule

   Go to the Resources tab and create a new Resource Set rule. This rule should validate if the user is the note’s owner.

   
3. Create a New Policy

   Return to the Policy tab and establish a policy allowing put and delete actions exclusively for the note’s owner. Ensure the admin role retains all-action privileges.

   
4. Test with a New User

   Log out from the current user, register a new user, and verify that this new user cannot delete tasks.

   
5. Create and Delete a Note

   As the new user, create a note and confirm the ability to delete the newly created note.

6. Cross-User Deletion Test

   Log in with a different user after creating the note and attempt to delete it. This should fail, as the logged-in user is not the creator.

Enforce Permissions Everywhere

Sometimes, you will encounter a situation where you need to check permissions in the middle of the application logic. For example, you could want to restrict a particular operation to premium users only.

Using Permit, the policy configuration always remains the same, and you’ll only have to use the permit.check function in every place within the code to determine allowed/not allowed permissions.

new Permit({token: <your_permit_token>});
permit.check(user, action, resource);

Using the permit.check function also lets you make decisions based on data that might not exist in the scope of the request in the middleware, so you get more granular decisions with no code changes.

Add Fine-Grained Relationship Based Authorization

Another approach for fine-grained authorization that we can use is Relationship-Based Access Control (ReBAC). Assuming a note app, we might want to create workspaces, organizations, and folders for our notes. In this case, we might do not have a dedicated owner field in the note entity, but we have a relationship between the note and the workspace.

Permit also supports the configuration of ReBAC policies, we can easily implement it in our application without changing the permit.check or any enforcement code in the app. Read more about modeling ReBAC here.