Using Hanko with Permit.io

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:

git clone <git@github.com>:permitio/permit-hanko.git

npm install 

npm run dev

​

Setting up Hanko Passkey Authentication:

<Paper sx={{ p: 2 }}>
  <HankoAuth />
</Paper>

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);
}

​

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).

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!

PERMIT_API_KEY=<YOUR_COPIED_API_KEY>

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

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

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.

​

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.