What is a JWT and why is it not sufficient for fine-grained access control
Tags: permissions, rbac, jwt
Published: 2024-05-07 08:46:00

---
title: What is a JWT and why is it not sufficient for fine-grained access control
published: true
description: While JWT (JSON Web Tokens) and session-based authentication mechanisms are robust tools for authenticating users and managing sessions, they fall short when it comes to fine-grained access control (FGA), which is where Space Blocks Permissions come into play.
tags: #permissions #rbac #jwt
cover_image: https://assets-global.website-files.com/63fe14edc64b772b050e759f/65e0cdbcfc7aa13ed4521e32_0_3.webp
# Use a ratio of 100:42 for best results.
published_at: 2024-05-07 08:46 +0000
canonical_url: https://www.spaceblocks.cloud/blog/what-is-jwt-and-why-is-it-not-sufficient-for-fine-grained-access-control
---

While JWT (JSON Web Tokens) and session-based authentication mechanisms are robust tools for authenticating users and managing sessions, they fall short when it comes to fine-grained access control (FGA), which is where Space Blocks Permissions come into play.

## Authentication vs. Authorization

In the realm of securing digital systems, two fundamental concepts often come into play: *authentication* and *authorization*. While authentication verifies the identity of a user, authorization dictates what actions they are allowed to perform within a system. So authentication is answering the question of *whom* the user is. Authorization answers the question of *what* the user is allowed to do.

## How does JWT work?

JWT (JSON Web Token) is a digitally signed JSON document, which includes information about the current user. It usually gets issued to the user by the identity provider, after a user signed in successfully. With every request, the user then sends the JWT to the backend, which can then verify its authenticity at the identity provider and, in case of a positive outcome, decide to let the user do, what they want to do.

![Example of a JWT from jwt.io](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/k8p7m91v0vb7o6fdu6qj.png)

The information about the user in the JWT’s payload are called claims. The [JWT Standard defines official claims](https://www.iana.org/assignments/jwt/jwt.xhtml#claims), that a token can have, but any identity provider can also add custom claims. A JWT can hold any kind of information, but usually, you can find the following claims:

- `iss` (issuer): Issuer of the JWT
- `sub` (subject): Subject of the JWT (the user)
- `aud` (audience): Recipient for which the JWT is intended
- `scope` (scope): Actions for which the JWT is intended
- `exp` (expiration time): Time after which the JWT expires
- `nbf` (not before time): Time before which the JWT must not be accepted for processing
- `iat` (issued at time): Time at which the JWT was issued; can be used to determine the age of the JWT

When it comes to authorization (checking, what a user is allowed to do), the `aud` (audience) and `scope` (scope) claims of a JWT are interesting. 

By checking the audience, a backend service can check, if a caller, that presents a certain token should be allowed to communicate with a specific backend or service (the audiences).

When defining APIs, developers often add scopes like `read:secrets` or `write:secrets` to their routes. Depending on how the user acquired the Access Token and which permissions that user has, different scopes are listed in a JWTs claims. Backend services can check these scopes against the ones they defined as required for their APIs, to decide if a user is allowed to call a certain API method or not.

## Why JWTs are insufficient for fine-grained access control

As you might have noticed in the example above, JWT claims like audience and scope can only be used to check, if a user can call a certain API method or interact with a certain service at all. It’s all or nothing. The `read:secrets` scope either allows a user to read secrets in your application or not.

The reality often looks different. In most applications, where users collaborate with and share resources among each other, they have different permissions on different resources. A user might have read and write permissions to all of their own folders, but only read permissions to those that got shared by a teammate. Some permissions can also imply access to other resources without explicitly mentioning them. Read access to a folder usually also implies access to the files and sub-folder within the shared folder. 

JWTs are great and have their place in the authorization space, but should only be used to determine if a user should be let into a system and how far. When it comes to fine-grained access control on resource level, a more sophisticated approach like Space Blocks Permissions is needed.

## Permissions as a Service with Space Blocks

With the [Space Blocks Permissions](https://www.spaceblocks.cloud) service, you can offload the burden of managing permissions, roles, groups and inheritance to our _Permissions as a Service_ system and focus on your core project. You can define the structure of your resources and their relationships, define permissions for them, create roles and then just let us know, whenever permissions got assigned or changed.

Your backend can still use JWT for basic authentication, but can check the Space Blocks API for fine-grained access control, once a user got let into your system. 

You can integrate Space Blocks into your backend code with a few lines of code and completely for free in the Developer Tier.