Microsoft does not offer a single-pane-of-glass dashboard or reporting function for Entra ID role management. Getting answers should not require a day’s worth of work. This is the gap that PIM Manager fills.
Hi Joël. Same goes for us. The question we keep getting from our cyber risk folks is who is getting access to our data and can it potentially be abused. In this case with app permissions I find it hard to answer or justify. Is the access key to our data stored somewhere and if your webservice gets compromised can our data be exfiltrated?
Hi! That is a very valid concern. I designed the architecture specifically with a "zero-knowledge" principle to address exactly this.
The app is a client-side Single Page Application (SPA) that runs entirely within your browser. It connects directly to the Microsoft Graph API. Since it has no backend server or database, your data never leaves your control and cannot be exfiltrated by me
Why no storage? Storing data would require external databases and application-based credentials (like Service Principals), which inherently introduces risks related to data transfer and persistent access. By deliberately avoiding storage and using Delegated permissions, I eliminate these attack vectors, making the solution significantly more secure by design.
All sensitive data is stored in Session Storage, which the browser automatically wipes the moment you close the tab. Additionally, clicking "Sign Out" explicitly forces a complete cleanup of all cached data, leaving only safe local preferences (like Dark Mode settings) behind.
I am open to all improvements, but it should not degrade (data) security, right?
any chance of sharing the code to allow for self hosting.
Hi! That’s not planned at this moment but something I will consider later on.
Just wondering, what would bring it in your situation? The app is fully build on web, there is no script or such.
Hi Joël. Same goes for us. The question we keep getting from our cyber risk folks is who is getting access to our data and can it potentially be abused. In this case with app permissions I find it hard to answer or justify. Is the access key to our data stored somewhere and if your webservice gets compromised can our data be exfiltrated?
Hi! That is a very valid concern. I designed the architecture specifically with a "zero-knowledge" principle to address exactly this.
The app is a client-side Single Page Application (SPA) that runs entirely within your browser. It connects directly to the Microsoft Graph API. Since it has no backend server or database, your data never leaves your control and cannot be exfiltrated by me
Why no storage? Storing data would require external databases and application-based credentials (like Service Principals), which inherently introduces risks related to data transfer and persistent access. By deliberately avoiding storage and using Delegated permissions, I eliminate these attack vectors, making the solution significantly more secure by design.
All sensitive data is stored in Session Storage, which the browser automatically wipes the moment you close the tab. Additionally, clicking "Sign Out" explicitly forces a complete cleanup of all cached data, leaving only safe local preferences (like Dark Mode settings) behind.
I am open to all improvements, but it should not degrade (data) security, right?
If the app were to be compromised the code can be changed and tokens can be harvested. Would still be great if you could make the code OS.
Hi Anders,
Thanks for reading and taking the time to comment!
I wrote another blog, in which I made it OS! So all the code, and the architecture and docs are available in the repo.
I got a lot of reactions which is great and some really useful feedback as well. So you can now run it locally if you want or need to!