2023 State of Authorization Report offers guidance on critical issues impacting authorization Learn more  

Stack Overflow: MERN Stack Authorization and Authentication

Are you working with MERN (Mongo, Express, React-redux, Node) and Authorization? This Stack Overflow post details the question at hand, and then how to use dynamic authorization with MERN. It originally appeared on Stack Overflow.


I am creating a MERN (Mongo, Express, React-redux, Node) stack app where I am adding authentication, authorization and access control features. I know how to implement the authentication service but don’t know how to implement the authorization and access control. For example: when user login then he will be able to create, edit and delete todo on his dashboard and no one will be able to see or edit that. How can I implement that? Any links, code or help would much be appreciated. Thanks a bunch!



This is a great question. And the answer is long :-) I just replied to a similar question here so you could start reading that.


What you are looking for is called externalized / dynamic authorization management. The formal model is called Attribute-Based Access Control ( / Wikipedia). It was formalized by the Nat’l Institute of Standards & Technology (NIST).

More in depth

You stated:

When user login then he will be able to create, edit and delete todo on his dashboard and no one will be able to see or edit that.

You need to write a policy using attributes that will allow users to do such things and prevent them from doing other things. If we rewrite your requirement, it becomes:

  • A user can create, edit, and delete a TODO item on a dashboard they own.
  • No one can see items on a dashboard they do not own.

Looking at the requirements, you realize you have:

  • a subject (or user) with their attributes (e.g. role, department…)
  • an action (e.g. view, edit, delete…)
  • an object or resource (the “TODO” item) and its container (the dashboard).

This means you can start rewriting your requirement in terms of attributes. This becomes:

  • A user can do action == "view" on object of type == "TODO" if user.username == object.dashboard.owner

You can then add:

  • deny all access if object.dashboard.owner != user.username

The language to write such policies is called ALFA ( / Wikipedia, the abbreviated language for authorization. It’s a standard defined by OASIS XACML.

Once you’ve defined your policies, you’ll need to deploy them, run them, and enforce them. This is where the ABAC architecture kicks in:

  • Policy Administration Point (PAP): where policies are written
  • Policy Decision Point (PDP): where policies are run / executed
  • Policy Enforcement Point (PEP): where policies are enforced – this could be an API gateway, an interceptor…
  • Policy Information Point (PIP): where additional metadata & attributes can be retrieved
The Attribute-Based Access Control (ABAC) Architecture

The question then becomes: where do you want to enforce? What does your MERN architecture look like? Do you want to authorize:

  • in the web UI? (functional authZ)
  • in the API layer (transactional authZ)
  • in the data layer (data-centric authZ / filtering)

For instance, do you want to filter data from MongoDB and only show allowed results? Do you want to apply authorization on the API layer? API gateways (e.g. Kong) can help you achieve that with authorization plugins e.g. Axiomatics-Kong.

There are open-source and commercial ABAC implementations and a standards body too (I’m the editor of some of the specs such as the JSON/REST request/response)


Archived under:
  Join us on LinkedIn for more insights
About the author

The world’s largest enterprises and government agencies continually depend on Axiomatics’ award-winning authorization platform to share sensitive, valuable and regulated digital assets – but only to authorized users and in the right context.