信頼のためのアーキテクチャ：ReactとExpressを用いたマルチロール管理プラットフォームの構築

How I designed a secure multi-role admin platform with JWT authentication, layered authorization, and role-specific workflows for Project Morpheus. When building an admin tool like Project Morpheus , the biggest security threat usually isn’t an external hacker. It’s Privilege Escalation . In a system with four distinct roles: Admin Warden Auditor Desk Operator how do you ensure that a desk volunteer can’t accidentally—or intentionally—delete audit logs or modify hostel configurations? Here’s how I architected a robust Role-Based Access Control (RBAC) system using React and Express. 1. The "Single Point of Truth" Authentication Model The foundation of the architecture is JWT-based authentication . When a user logs in, the backend issues a signed token containing: userId role hostelId (for Warden accounts) This token is stored in the browser and sent with every API request through the Authorization header. Authorization: Bearer <jwt_token> The hostelId field allows wardens to be automatically restricted to their assigned building. This became the foundation for permission-aware APIs and role-specific dashboards. 2. The Hybrid API: Performance Meets Portability I wanted the platform to work seamlessly in: Local development Cloud/serverless deployments So I used a Hybrid Express + Serverless Architecture . Local Development A central Express server.js handles: Routing Middleware JWT validation Local API orchestration Production Deployment Each route is structured as an independent serverless function: /api/teams/verify.js /api/hostels/allocate.js /api/audit/logs.js This approach gave me: Better modularity Easier debugging Isolated feature testing Cloud portability without maintaining two different codebases. 3. Defense in Depth: The "Double Lock" Strategy One of the most common security mistakes in frontend-heavy applications is: Protecting only the UI. Hiding buttons in React does not secure your system. Anyone with: Postman curl browser devtools can still hit your APIs directly. So Morpheus uses a Two-Layer Guard Architecture . Layer 1: Frontend Route Guards (UX Protection) In React, I implemented a wrapper component that validates roles before rendering routes. const ProtectedRoute = ({ allowedRoles , children }) => { const { user } = useAuth (); if ( ! allowedRoles . includes ( user . role )) { return < Navigate to = "/unauthorized" />; } return children ; }; This ensures: Wardens never see admin settings Desk operators never access audit tools Auditors only see verification workflows The frontend becomes cleaner and less error-prone. Layer 2: Backend Middleware (Real Security) Every API route is wrapped in authorization middleware. Even if someone bypasses the UI, the server validates: JWT authenticity User role Permission level Resource ownership before processing the request. Example: if ( req . user . role !== " Admin " ) { return res . status ( 403 ). json ({ error : " Access denied " }); } This creates true defense-in-depth security. 4. Designing for Specific Roles One of the most impactful decisions in Morpheus was making the interface adapt to the user’s identity. Different users think differently. So the UI itself changes depending on the role. The Desk Operator Their workflow is optimized for: Speed Search Verification They need to: Find teams instantly Search by phone number or ID Verify attendance rapidly Minimal distractions. Maximum efficiency. The Warden Their workflow is visual. They need: Occupancy heatmaps Room status visibility Floor-level overview dashboards Instead of forms, they interact with live hostel state. The Auditor Auditors care about process integrity. Their interface is workflow-oriented: Step-by-step validation Approval pipelines Verification checkpoints Historical records They don’t need dashboards. They need structured operational flows. 5. Key Architecture Takeaways Building Morpheus taught me several important engineering lessons. Never Trust the Client Always verify permissions on the backend. Frontend validation improves UX. Backend validation provides security. You need both. Modular APIs Scale Better Small domain-focused handlers are easier to: Test Maintain Secure Deploy independently Context is King Using: React Context Custom Hooks Global Auth Providers allowed me to avoid painful prop-drilling across deeply nested dashboards. Security Is Also About Preventing Mistakes One of the biggest realizations during this project was: Security isn’t just about stopping attackers. It’s also about designing systems that prevent normal users from making catastrophic mistakes. Good architecture guides users toward safe behavior by default. That matters just as much as encryption and middleware. Final Thoughts Building Project Morpheus pushed me to think beyond CRUD applications and into operational system design. Once you introduce: Multiple roles Real-world workflows Permissions Auditability Physical asset management your application becomes less about pages and more about trust boundaries. And designing those trust boundaries correctly is where backend architecture becomes truly interesting. Discussion How would you design RBAC in a large-scale operational platform? Would you use: Attribute-Based Access Control (ABAC)? Policy Engines like OPA? Role hierarchies? Permission matrices? Microservice authorization gateways? I’d love to hear how other engineers approach multi-role security systems. How I designed a secure multi-role admin platform with JWT authentication, layered authorization, and role-specific workflows for Project Morpheus. When building an admin tool like Project Morpheus , the biggest security threat usually isn’t an external hacker. It’s Privilege Escalation . In a system with four distinct roles: Admin Warden Auditor Desk Operator how do you ensure that a desk volunteer can’t accidentally—or intentionally—delete audit logs or modify hostel configurations? Here’s how I architected a robust Role-Based Access Control (RBAC) system using React and Express. 1. The "Single Point of Truth" Authentication Model The foundation of the architecture is JWT-based authentication . When a user logs in, the backend issues a signed token containing: userId role hostelId (for Warden accounts) This token is stored in the browser and sent with every API request through the Authorization header. Authorization: Bearer <jwt_token> The hostelId field allows wardens to be automatically restricted to their assigned building. This became the foundation for permission-aware APIs and role-specific dashboards. 2. The Hybrid API: Performance Meets Portability I wanted the platform to work seamlessly in: Local development Cloud/serverless deployments So I used a Hybrid Express + Serverless Architecture . Local Development A central Express server.js handles: Routing Middleware JWT validation Local API orchestration Production Deployment Each route is structured as an independent serverless function: /api/teams/verify.js /api/hostels/allocate.js /api/audit/logs.js This approach gave me: Better modularity Easier debugging Isolated feature testing Cloud portability without maintaining two different codebases. 3. Defense in Depth: The "Double Lock" Strategy One of the most common security mistakes in frontend-heavy applications is: Protecting only the UI. Hiding buttons in React does not secure your system. Anyone with: Postman curl browser devtools can still hit your APIs directly. So Morpheus uses a Two-Layer Guard Architecture . Layer 1: Frontend Route Guards (UX Protection) In React, I implemented a wrapper component that validates roles before rendering routes. const ProtectedRoute = ({ allowedRoles , children }) => { const { user } = useAuth (); if ( ! allowedRoles . includes ( user . role )) { return < Navigate to = "/unauthorized" />; } return children ; }; This ensures: Wardens never see admin settings Desk operators never access audit tools Auditors only see verification workflows The frontend becomes cleaner and less error-prone. Layer 2: Backend Middleware (Real Security) Every API route is wrapped in authorization middleware. Even if someone bypasses the UI, the server validates: JWT authenticity User role Permission level Resource ownership before processing the request. Example: if ( req . user . role !== " Admin " ) { return res . status ( 403 ). json ({ error : " Access denied " }); } This creates true defense-in-depth security. 4. Designing for Specific Roles One of the most impactful decisions in Morpheus was making the interface adapt to the user’s identity. Different users think differently. So the UI itself changes depending on the role. The Desk Operator Their workflow is optimized for: Speed Search Verification They need to: Find teams instantly Search by phone number or ID Verify attendance rapidly Minimal distractions. Maximum efficiency. The Warden Their workflow is visual. They need: Occupancy heatmaps Room status visibility Floor-level overview dashboards Instead of forms, they interact with live hostel state. The Auditor Auditors care about process integrity. Their interface is workflow-oriented: Step-by-step validation Approval pipelines Verification checkpoints Historical records They don’t need dashboards. They need structured operational flows. 5. Key Architecture Takeaways Building Morpheus taught me several important engineering lessons. Never Trust the Client Always verify permissions on the backend. Frontend validation improves UX. Backend validation provides security. You need both. Modular APIs Scale Better Small domain-focused handlers are easier to: Test Maintain Secure Deploy independently Context is King Using: React Context Custom Hooks Global Auth Providers allowed me to avoid painful prop-drilling across deeply nested dashboards. Security Is Also About Preventing Mistakes One of the biggest realizations during this project was: Security isn’t just about stopping attackers. It’s also about designing systems that prevent normal users from making catast