DEV Community: Alex Olivier

The Case Against Token-Based Authorization

Alex Olivier — Mon, 31 Jan 2022 10:09:57 +0000

Have you ever scaled out a web application or an API? If so, you’ll have noticed your out-of-the-box web framework stores its user session in memory. You may have utilized sticky sessions in response, or stored your sessions in a shared database—but these solutions aren’t without problems. For example, in a shared database, you’d need to make an extra request to the database for every HTTP request.

To account for such flaws, using a form of stateless authentication allows for better application scalability, as well as more efficient authentication of HTTP requests. Token-based authentication is perhaps the most common stateless authentication strategy, and JSON Web Tokens (JWTs) are today’s token of choice.

While using JWTs for authentication is extremely common, some application developers are building authorization and permissions directly into their web tokens, risking serious security implications as a result. Baking authorization directly into JWTs also comes with several limitations that should be avoided.

Data inside of JWTs are generally not encrypted, leaving them human-readable. While this lack of encryption is by design, it comes with some serious concerns around storing private, sensitive, and authorization-based information in JWTs. This is especially true when your organization is under certain regulatory compliance like HIPAA or SOC 2.

In this article, you’ll learn why application developers should avoid using JWTs for authorization.

Defining JWTs

JWTs are like a key. A web application gives a client a token, which the client then uses to access protected resources. JWTs are composed of three parts: a header, a payload, and a signature.

The header contains meta-information about the JWT.

The payload contains the information used to identify the owner of the token: user ID, email address, etc. These are called claims. A standard set of claims exists to ensure collisions of claim names are avoided. That being said, JWT payloads can hold custom claims. Essentially, this means they can hold whatever information you may need.

The signature is what makes a JWT secure: it’s a way to verify if a token was created from the same issuer, and ensure it hasn't been tampered with.

JWTs are usually not encrypted. The information within the header and payload is encoded (not encrypted), which means it can be decoded. The key to keeping JWTs secure is ensuring the header and payload are hashed using a secret, which is similar to hashing a password. The resulting hash is the signature that’s part of the JWT.

Any party with access to a secret can use it to hash the header and payload values it receives and verify that the signature matches. If the hash and token signature don’t match, it means the JWT header and/or payload were tampered with.

Token-Based Authentication

Token-based authentication is when you use a JWT (or other token technology) to verify the identity of a client.

One of the most common benefits of using a JWT for authentication is not having to fetch user data from a database; you already have the essential user information embedded directly in the token. Whenever an API receives an HTTP request with a valid JWT, it extracts the user’s information and uses it as needed.

This is why we call JWTs stateless: the API’s server doesn’t need to keep track of a user’s session state.

Token-Based Authorization

Similar to using JWTs for stateless authentication, JWTs can also be used to store authorization-based information like user permissions and roles.

Storing a user’s role in a JWT means you won’t need to query a database to know whether a particular JWT is permitted to access certain resources. Based on this, JWTs can provide performance and scalability gains when it comes to authorization.

As a software engineer, you often have to make trade-offs between security and performance. For example, modern password hashing techniques often sacrifice speed for added security. These techniques utilize high hashing iterations, avoiding timing attacks by using a constant equality operation to compare hashes.

While storing authorization information in JWTs offers significant performance benefits, serious concerns emerge as a result. Let’s break down some of the most pressing:

JWT Payload Is Visible

With JWTs, all payload data is visible to the parties who have token access; to reiterate—they aren’t encrypted, but encoded. Authorization information may be considered sensitive information for a particular system, especially when your software systems are under compliance and governance restrictions.

For example, personally identifiable information such as a person’s name, email address, or phone number are all considered protected health information under HIPAA. If you’re storing this kind of data in JWTs while under HIPAA compliance, you could have a major security and compliance risk on your hands depending on where your JWTs are being used (internal network vs. public client).

Note: There are techniques that can help protect user information tokens, like using phantom tokens. However, this makes using JWTs much more involved and complicated.

Stale Payload

Imagine a token for a customer named Bob has a payload identifying him as an admin. It’s discovered that Bob is a bad actor (a spy or an upset employee). As a result, you disable Bob from inside your web application. Except… the JWT that Bob is using from his mobile application hasn’t expired yet.

Bob can keep issuing requests until the JWT expires. Since authorization is baked into the token, you aren’t querying the database to get the most up-to-date information about Bob’s role or permissions. Bob can continue to do damage to your system—even though he’s supposed to be disabled.

There are two common ways to avoid this scenario:

Make tokens extremely short-lived (e.g. every five minutes).
Store all tokens in a database, and allow your web application to revoke them.

But these “solutions” come with their own issues.

Short-lived tokens don’t necessarily solve your problem. It wouldn’t take long for a disgruntled and disabled administrator to harm a system—even less than five minutes. This can also cause user experience issues for clients; they would have to refresh their access token more often, or sign-in to the service again. Negatively impacting user experience is something you should always try to avoid.

Storing valid tokens in a database so they can be revoked destroys the main reason for using JWTs in the first place—to avoid unnecessary trips to your database.

One of the best ways to mitigate this is to store user roles and permissions in a dedicated access control tool like Cerbos. You could also store user permission information in an efficient storage system like Redis.

Bloated JWTs

JWTs are much larger than the standard session cookies that a web application would typically use. Once you start adding more data into a JWT’s payload, its size may cause HTTP requests to perform slower.

HTTP headers have size limits too, depending on the web server stack being used.

JWTs Are Complex

Once you go beyond the basics, implementing JWTs is complicated, increasing the chances of developers making mistakes as a result. For example, even Auth0—one of the sponsors of JWT.io—had a JWT vulnerability with their API back in 2020!

Similarly, improperly configuring your JWT by using a third-party library or service could allow someone else to attack your system—something you want to avoid at all costs.

JWTs Are Not a Cache

JWTs are not a cache—they shouldn’t be treated as a caching technology. It can be easy to shove as much information about a user and associated resources into your tokens as possible, but that doesn’t mean you should.

Again, this data is not hidden to anyone who can see the JWT. All data in the payload is stale, which can affect the performance of HTTP requests.

Much like the issue with stale data in JWT payloads, you should use an efficient caching technology to cache data, or a dedicated access control service like Cerbos.

You’ll Eventually Need to Fetch a User Anyway

JWTs are supposed to help you avoid making extra database requests to fetch user information. Despite this, it’s routine to query your database to fetch extra user information.

Any non-trivial piece of business logic will need to know details about a user: what department they’re part of, special mappings to resources in your system, special business rules that can’t be expressed by a mere data attribute, etc.

It doesn’t make sense to bloat your JWTs when you’re going to need to fetch that same information (and more) anyway.

Conclusion

JWTs can be a great way to authenticate clients, giving them a way to access protected resources by using a short-lived token as a ”key”. When it comes to making distributed services more scalable and efficient, JWTs shine.

However, when it comes to storing authorization details, JWTs come with a number of risks. JWTs come with the added cost of larger HTTP requests, negatively impacting HTTP performance. Depending on your traffic, this could cause a significant increase in the associated usage costs of your cloud services, slower endpoints, and the risk of blowing past HTTP header size limits.

In addition to performance issues, JWTs face regulatory compliance difficulties, as well as expiration problems which leave you open to system attacks. Plus, you’ll probably be fetching user information from a cache or database anyway.

This is why a dedicated access control service like Cerbos can be a better option. Cerbos’ ultra-fast API is designed to make access control decisions within milliseconds, while providing a simple way to configure them. To learn more, check out Cerbos.dev.

Adding Authorization to Your Node.js Application Using Cerbos

Alex Olivier — Mon, 06 Dec 2021 10:47:26 +0000

Authorization is critical to web applications. It grants the correct users access to sections of your web application on the basis of their roles and permissions. In a simple application, adding in-app authorization to your application is relatively straightforward. But with complex applications comes a need to create different roles and permissions, which can become difficult to manage.

In this tutorial, you’ll learn how to use Cerbos to add authorization to a Node.js web application, simplifying the authorization process as a result.

Setting Up the Node.js Application

Before we get started with Cerbos, you’ll need to create a new Node.js application (or use an existing one). Let’s set up a blog post Node.js application as our example.

Defining User Permissions

The blog post application will contain two roles: member and moderator.

The member role will have the following permissions:

– create a new blog post
– update blog posts created by the member
– delete blog posts created by the member
– view all blog posts created by all members
– view a single blog post created by any member

The moderator role will have the following permissions:

– view all blog posts created by all members
– view a single blog post created by any member
– disable and enable a malicious post

Members and moderators cannot perform any action if they are disabled.

Creating the Application

Step 1

Launch your terminal or command-line tool and create a directory for the new application:

mkdir blogpost

Step 2

Move into the blog post directory and run the command below—a package.json file will be created:

npm init -y

Step 3

Open the package.json file and paste the following:

{
    "name": "blogpost",
    "version": "1.0.0",
    "description": "",
    "main": "index.js",
    "scripts": {
        "start": "nodemon index.js",
        "test": "mocha --exit --recursive test/**/*.js"
    },
    "keywords": [],
    "author": "",
    "license": "ISC",
    "dependencies": {
        "cerbos": "0.0.3",
        "express": "^4.17.1"
    },
    "devDependencies": {
        "chai": "^4.3.4",
        "chai-http": "^4.3.0",
        "mocha": "^9.0.3",
        "nodemon": "^2.0.12"
    }
}

Two main packages are in the dependencies section of thepackage.json—Cerbos and Express:

Cerbos is the authorization package responsible for creating roles and permissions.
Express is a Node.js framework used to set up and create faster server-side applications.

In the devDependencies, there are four packages: Chai, Chai HTTP, Mocha, and Nodemon. Chai, Chai HTTP, and Mocha are used to run automated test scripts during and after development. Nodemon is used to ensure the application server is restarted whenever a change is made to any file during development.

Step 4

Run npm install to install the packages in the package.json.

Step 5

Create the following files:

– index.js, which contains the base configuration of the demo application.
– routes.js, which contains all the routes needed in the demo application.
– db.js, which exports the demo database. For the sake of this demo, you will be using an array to store the data—you can use any database system you desire.
– authorization.js, which contains the Cerbos authorization logic.

    touch index.js routes.js db.js authorization.js

Then, paste the following codes in the respective files:

//index.js

const express = require("express");
const router = require("./routes");
const app = express();

app.use(express.urlencoded({ extended: true }));
app.use(express.json());

app.use("/posts", router);
app.use((error, req, res, next) => {
  res.status(400).json({
    code: 400,
    message: error.stack,
  });
});

app.listen(3000, () => {
  console.log("App listening on port 3000!");
});

module.exports = app;

//routes.js

const express = require("express");
const router = express.Router();
const db = require("./db");
const authorization = require("./authorization");

const checkPostExistAndGet = (id) => {
  const getPost = db.posts.find((item) => item.id === Number(id));
  if (!getPost) throw new Error("Post doesn't exist");
  return getPost;
};

router.post("/", async (req, res, next) => {
  try {
    const { title, content } = req.body;
    const { user_id: userId } = req.headers;

    await authorization(userId, "create", req.body);

    const newData = {
      id: Math.floor(Math.random() * 999999 + 1),
      title,
      content,
      userId: Number(userId),
      flagged: false,
    };
    db.posts.push(newData);

    res.status(201).json({
      code: 201,
      data: newData,
      message: "Post created successfully",
    });
  } catch (error) {
    next(error);
  }
});

router.get("/", async (req, res, next) => {
  try {
    const getPosts = db.posts.filter((item) => item.flagged === false);

    const { user_id: userId } = req.headers;
    await authorization(userId, "view:all");

    res.json({
      code: 200,
      data: getPosts,
      message: "All posts fetched successfully",
    });
  } catch (error) {
    next(error);
  }
});

router.get("/:id", async (req, res, next) => {
  try {
    const getPost = db.posts.find(
      (item) => item.flagged === false && item.id === Number(req.params.id)
    );

    const { user_id: userId } = req.headers;
    await authorization(userId, "view:single");

    res.json({
      code: 200,
      data: getPost,
      message: "Post fetched successfully",
    });
  } catch (error) {
    next(error);
  }
});

router.patch("/:id", async (req, res, next) => {
  try {
    const { title, content } = req.body;
    let updatedContent = { title, content };
    const { user_id: userId } = req.headers;

    const postId = req.params.id;
    checkPostExistAndGet(postId);

    const tempUpdatedPosts = db.posts.map((item) => {
      if (item.id === Number(postId)) {
        updatedContent = {
          ...item,
          ...updatedContent,
        };
        return updatedContent;
      }
      return item;
    });

    await authorization(userId, "update", updatedContent);

    db.posts = tempUpdatedPosts;

    res.json({
      code: 200,
      data: updatedContent,
      message: "Post updated successfully",
    });
  } catch (error) {
    next(error);
  }
});

router.delete("/:id", async (req, res, next) => {
  try {
    const { user_id: userId } = req.headers;
    const postId = req.params.id;
    const post = checkPostExistAndGet(postId);

    const allPosts = db.posts.filter(
      (item) => item.flagged === false && item.id !== Number(postId)
    );

    await authorization(userId, "delete", post);

    db.posts = allPosts;

    res.json({
      code: 200,
      message: "Post deleted successfully",
    });
  } catch (error) {
    next(error);
  }
});

router.post("/flag/:id", async (req, res, next) => {
  try {
    let flaggedContent = {
      flagged: req.body.flag,
    };
    const { user_id: userId } = req.headers;

    const postId = req.params.id;
    checkPostExistAndGet(postId);

    const tempUpdatedPosts = db.posts.map((item) => {
      if (item.id === Number(postId)) {
        flaggedContent = {
          ...item,
          ...flaggedContent,
        };
        return flaggedContent;
      }
      return item;
    });

    await authorization(userId, "flag", flaggedContent);

    db.posts = tempUpdatedPosts;

    res.json({
      code: 200,
      data: flaggedContent,
      message: `Post ${req.body.flag ? "flagged" : "unflagged"} successfully`,
    });
  } catch (error) {
    next(error);
  }
});

module.exports = router;

//db.js

const db = {
  users: [
    {
      id: 1,
      name: "John Doe",
      role: "member",
      blocked: false,
    },
    {
      id: 2,
      name: "Snow Mountain",
      role: "member",
      blocked: false,
    },
    {
      id: 3,
      name: "David Woods",
      role: "member",
      blocked: true,
    },
    {
      id: 4,
      name: "Maria Waters",
      role: "moderator",
      blocked: false,
    },
    {
      id: 5,
      name: "Grace Stones",
      role: "moderator",
      blocked: true,
    },
  ],
  posts: [
    {
      id: 366283,
      title: "Introduction to Cerbos",
      content:
        "In this article, you will learn how to integrate Cerbos authorization into an existing application",
      userId: 1,
      flagged: false,
    },
  ],
};

module.exports = db;

The demo database includes five users, consisting of three members and two moderators. Among the three members, there are two active members and one blocked member. Among the two moderators, one is an active moderator and the other is a blocked moderator.

In the meantime, the authorization.js will contain an empty scaffolding to see how the application works, before integrating the Cerbos authorization package:

module.exports = async (principalId, action, resourceAtrr = {}) => {

};

Step 6

The demo application has been successfully set up. It’s now time to see how the application looks before integrating the Cerbos authorization package.

Start the server with the command below:

npm run start

You should see the following in your terminal to indicate your application is running on port 3000:

[nodemon] 2.0.12
[nodemon] to restart at any time, enter `rs`
[nodemon] watching path(s): *.*
[nodemon] watching extensions: js,mjs,json
[nodemon] starting `node index.js`
App listening on port 3000!

Testing the Application Without Authorization

Now it’s time to test the application. You can use any HTTP client of your choice, such as Postman, Insomnia, or cURL. For this example, we’ll use cURL.

Make the following requests—you should find no restrictions. Change the user_ID from 1 through 5, and you should receive a valid response.

Create Post

curl --location --request POST 'http://localhost:3000/posts/' --header 'user_id: 1' --header 'Content-Type: application/json' --data-raw '{
    "title": "Introduction to Cerbos",
    "content": "Welcome to Cerbos authorization package"
}'

Update Post

curl --request PATCH 'http://localhost:3000/posts/351886' --header 'user_id: 1' --header 'Content-Type: application/json' --data-raw '{
    "title": "Welcome to Cerbos",
    "content": "10 things you need to know about Cerbos"
}'

View All Posts

curl --request GET 'http://localhost:3000/posts/' --header 'user_id: 1'

View Single Post

curl --request GET 'http://localhost:3000/posts/366283' --header 'user_id: 1'

Flag Post

curl --request POST 'http://localhost:3000/posts/flag/366283' --header 'user_id: 5' --header 'Content-Type: application/json' --data-raw '{
    "flag": true
}'

Delete Post

curl --request DELETE 'http://localhost:3000/posts/366283' --header 'user_id: 1'

Integrating Cerbos Authorization

As things stand, the application is open to authorized and unauthorized actions. Now, it’s time to implement Cerbos to ensure users perform only authorized operations.

To get started, a policy folder needs to be created to store Cerbos policies. Cerbos uses these policies to determine which users have access to what resources. In the blog post directory, run the command below to create a directory called Cerbos. This will contain the policy directory:

mkdir cerbos && mkdir cerbos/policies

Next, switch to the policies folder and create two policy YAML files: derived_roles.yaml and resource_post.yaml.

The `derived_roles.yaml` File Description

Derived roles allow you to create dynamic roles from one or more parent roles. For example, the role member is permitted to view all blog posts created by other members, but is not allowed to perform any edit operation. To allow owners of a blog post who are also members make edits on their blog post, a derived role called owner is created to grant this permission.

Now paste the code below in your derived_roles.yaml:

---
# derived_roles.yaml

apiVersion: "api.cerbos.dev/v1"
derivedRoles:
  name: common_roles
  definitions:
    - name: all_users
      parentRoles: ["member", "moderator"]
      condition:
        match:
          expr: request.principal.attr.blocked == false

    - name: owner
      parentRoles: ["member"]
      condition:
        match:
          all:
            of:
              - expr: request.resource.attr.userId == request.principal.attr.id
              - expr: request.principal.attr.blocked == false

    - name: member_only
      parentRoles: ["member"]
      condition:
        match:
          expr: request.principal.attr.blocked == false

    - name: moderator_only
      parentRoles: ["moderator"]
      condition:
        match:
          expr: request.principal.attr.blocked == false

    - name: unknown
      parentRoles: ["unknown"]

– apiVersion is the current version of the Cerbos derived role.
– derivedRoles contains the list of user roles that your application will be used for; each role will be configured based on the needs of the application.
– derivedRoles (name) allows you to distinguish between multiple derived roles files in your application that can be used in your resource policies.
– derivedRoles (definitions) is where you’ll define all the intended roles to be used in the application.
– name is the name given to the derived roles generated; for example, a resource could be accessed by members and moderators. With the help of derived roles, it’s possible to create another role that will grant permissions to the resource.
– parentRoles are the roles to which the derived roles apply, e.g. members and moderators.
– condition is a set of expressions that must hold true for the derived roles to take effect. For example, you can create derived roles from members and moderators, then add a condition that the derived roles can only take effect if members or moderators are active. This can be done through the condition key. For more information on conditions, check the condition guide here.

The `resource_post.yaml` File Description

The resource policy file allows you to create rules for parent/derived roles on different actions that can be performed on a resource. These rules inform the roles if they have permission to perform certain actions on a resource.

Paste the following code in your resource_post.yaml:

---
# resource_post.yaml

apiVersion: api.cerbos.dev/v1
resourcePolicy:
  version: "default"
  importDerivedRoles:
    - common_roles
  resource: "blogpost"
  rules:
    - actions: ['view:all']
      effect: EFFECT_ALLOW
      derivedRoles:
        - all_users

    - actions: ['view:single']
      effect: EFFECT_ALLOW
      roles:
        - moderator
        - member

    - actions: ['create']
      effect: EFFECT_ALLOW
      derivedRoles:
        - member_only

    - actions: ['update']
      effect: EFFECT_ALLOW
      derivedRoles:
        - owner
        - moderator_only
      condition:
        match:
          any:
            of:
              - expr: request.resource.attr.flagged == false && request.principal.attr.role == "member"
              - expr: request.resource.attr.flagged == true && request.principal.attr.role == "moderator"

    - actions: ['delete']
      effect: EFFECT_ALLOW
      derivedRoles:
        - owner

    - actions: ['flag']
      effect: EFFECT_ALLOW
      derivedRoles:
        - moderator_only

The resource policy file contains the permissions each role or derived roles can have access to:

– apiVersion is the version for the resource policy file.
– resourcePolicy holds all the key attributes of the resource policy.
– version is used to identify the policy that should be used in the application; you can have multiple policy versions for the same resource.
– importDerivedRoles is used to specify the type of derived roles you want to import into the resource policy file.
– resource contains the resource you want to apply the roles and permissions to.
– rules is where you will set the rules for different operations, on the basis of user permissions.
– actions are operations to be performed.
– effect is to indicate whether to grant the user access to the operation, based on the roles and derived roles (and conditions, if they exist).
– derivedRoles contains the derived roles you formed in your derived_roles yaml file.
– roles are static default roles used by your application.
– condition specifies conditions that must be met before access can be granted to the operation.

To ensure your policy’s YAML files do not contain errors, run this command in the blog post root directory. If it doesn’t return anything, then it is error-free:

docker run -i -t -v $(pwd)/cerbos/policies:/policies ghcr.io/cerbos/cerbos:0.10.0 compile /policies

Spinning Up the Cerbos Server

You’ve now successfully created the policy files that Cerbos will be using to authorize users in your application. Next, it’s time to spin the Cerbos server up by running the below command in your terminal:

docker run --rm --name cerbos -d -v $(pwd)/cerbos/policies:/policies -p 3592:3592 ghcr.io/cerbos/cerbos:0.6.0

Your Cerbos server should be running at http://localhost:3592. Visit the link, and if no error is returned the server is working fine.

Implementing Cerbos Into the Application

Now it’s time to fill the empty scaffolding in the authorization.js file:

const { Cerbos } = require("cerbos");
const db = require("./db");

const cerbos = new Cerbos({
  hostname: "http://localhost:3592", // The Cerbos PDP instance
});

module.exports = async (principalId, action, resourceAtrr = {}) => {
  const user = db.users.find((item) => item.id === Number(principalId));

  const cerbosObject = {
    actions: ["create", "view:single", "view:all", "update", "delete", "flag"],
    resource: {
      policyVersion: "default",
      kind: "blogpost",
      instances: {
        post: {
          attr: {
            ...resourceAtrr,
          },
        },
      },
    },
    principal: {
      id: principalId || "0",
      policyVersion: "default",
      roles: [user?.role || "unknown"],
      attr: user,
    },
    includeMeta: true,
  };

  const cerbosCheck = await cerbos.check(cerbosObject);

  const isAuthorized = cerbosCheck.isAuthorized("post", action);

  if (!isAuthorized)
    throw new Error("You are not authorized to visit this resource");
  return true;
};

The cerbosObject is the controller that checks if a user has access to certain actions. It contains the following keys:

– Actions contains all of the available actions you’ve created in the resource policy file.
– Resource allows you to indicate which resource policy you want to use for the resource request from multiple resource policy files.
– The policyVersion in the resource key maps to version in the resource policy
file.
– kind maps to resource key in the resource policy file.
– Instances can contain multiple resource requests that you want to test against the
resource policy file. In the demo, you are only testing the blog post resource.
– Principal contains the details of the user making the resource request at that instance.

The cerbosCheck.isAuthorized() method is used to check if the user/principal is authorized to perform the requested action at that instance.

Testing Cerbos Authorization with the Blog Post Application

You have successfully set up the required roles and permissions for each operation in the CRUD blog post demo application. It’s now time to test the routes again and observe what happens, using the table below as a guide for testing:

action	user_id	user_role	user_status	response
create, view:all, view:single	1 and 2	member	active	OK
All Actions	3	member	blocked	Not authorized
All Actions	5	moderator	blocked	Not authorized
Update its own post	1	member	active	OK
Update another user post	1	member	active	Not authorized

The above table displays a subset of the different permissions for each user implemented in the demo application.

You can clone the demo application repository from GitHub. Once you’ve cloned it, follow the simple instructions in the README file. You can run the automated test script to test for the different user roles and permissions.

Conclusion

In this article, you’ve learned the benefits of Cerbos authorization by implementing it in a demo Node.js application. You’ve also learned the different Cerbos policy files and their importance in ensuring authorization works properly.

For more information about Cerbos, you can visit the official documentation here.

DEV Community: Alex Olivier

The Case Against Token-Based Authorization

Defining JWTs

Token-Based Authentication

Token-Based Authorization

JWT Payload Is Visible

Stale Payload

Bloated JWTs

JWTs Are Complex

JWTs Are Not a Cache

You’ll Eventually Need to Fetch a User Anyway

Conclusion

Adding Authorization to Your Node.js Application Using Cerbos

Setting Up the Node.js Application

Defining User Permissions

Creating the Application

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Testing the Application Without Authorization

Create Post

Update Post

View All Posts

View Single Post

Flag Post

Delete Post

Integrating Cerbos Authorization

The derived_roles.yaml File Description

The resource_post.yaml File Description

Spinning Up the Cerbos Server

Implementing Cerbos Into the Application

Testing Cerbos Authorization with the Blog Post Application

Conclusion

The `derived_roles.yaml` File Description

The `resource_post.yaml` File Description