Announcing MCP Authentication: secure your MCP servers with PropelAuth

We’re happy to share the latest update to PropelAuth—adding more customizability to role based access control (RBAC), so you can have full control over what your users can see and do within your product.

Within your customer's organizations, you typically will want some users to have more access than others. Maybe only Admin s can view the billing page. Maybe you have a ReadOnly role which can fetch data but not write data.

Configuring Your Product's Roles

Now you can customize your role names to match your product's nomenclature. Let’s say you sell to restaurants. Our default Roles (“Owner”, “Admin”, and “Member”) don’t accurately match your product's users, so now you can rename them to “Manager”, “Chef”, and “Waiter.”

With customizable roles, your company can create an auth experience that feels like a natural part of your product.

What can I do with roles?

PropelAuth's libraries treat these roles as a first-class concept on both the frontend and backend. You can then easily:

• Reject an HTTP request if the user is not at least an Admin in their organization/tenant
• Conditionally render the frontend based on the user's role. Want to hide the Edit button for users with the role ReadOnly? You can do that in a single line of code.
• Limit who can send organization invitations based on their role

These can be done with middleware functions as simple as this Express example:

app.get("/org/:orgId/admin",
    requireOrgMemberWithExactRole({role: "Admin"}),
    (req, res) => {
        res.text("You are an Admin of " + req.org.orgName)
    }
)

Also Introducing: Permissions

The purpose of Roles is to give a developer more control over what users can see and do within their application.

However, it may be easier to think about what a user can do as opposed to the user's role.

In our example above, we might structure our product like:

• Manager - canInviteEmployees, canSetWorkingHours, canViewMenu
• Chef - canEditMenu, canViewMenu
• Waiter - canViewMenu

In our product now, instead of asking "is this user a chef?" we can instead ask "does this user have permission to edit the menu?".

You can manage these permissions in your dashboard and your users will automatically get permissions based on their role.

Summary

With PropelAuth’s RBAC support, you can skip building roles, permissions, and all the authorization middleware yourself.

Additionally, our RBAC support is self-service, meaning we also include UIs your customers can use to manage their own accounts.

Whether you choose our default roles or customize them to your organization’s needs, our RBAC options will make user management more efficient for both you and your users.

If you’re ready to add RBAC to your own project, you can start here.