Henry_CQ: Authentication & Role-Based Security Verification (Current + Future Capabilities)
1. Is role-based access supported (admin/user/custom roles)?
2. Can we apply role rules per route or per table?
3. How are passwords stored (strong hashing)?
4. What is the session duration? Is auto logout supported?
5. Is a refresh token used or only session cookies?
6. Are HTTP-only cookies used?
7. Is there secure email verification and password reset flow?
8. Is rate limiting / brute-force protection implemented?
9. Can sessions be revoked / force logout supported?
10. Can advanced roles or SSO be added in the future?
Riya_NoCodeBackend
Feb 21, 2026A: Hey — great security checklist. Below is a clear overview of our current capabilities and what’s planned.
1️⃣ Role-based access
We support Row Level Security (RLS) with three access modes:
• Private — only the data owner can access
• Shared — all authenticated users can access
• Public — no authentication required
Named roles like “admin” or custom roles are not built-in today but are planned for future expansion (see #10).
2️⃣ Rules per route or per table
Access policies are configured per table, and both authenticated and public API routes automatically enforce the table-level policy you’ve defined.
3️⃣ Password storage
Passwords are never stored in plaintext. We use industry-standard bcrypt hashing for secure password storage.
4️⃣ Session duration / auto logout
Sessions have a 7-day duration and automatically expire after that period, effectively acting as auto logout. Active sessions are refreshed during use to keep users signed in while they remain active.
5️⃣ Refresh tokens vs cookies
We currently use session cookies only. Sessions are extended on activity so users remain logged in while actively using the app.
6️⃣ HTTP-only cookies
Yes — session cookies are HTTP-only and use the Secure flag on HTTPS, preventing client-side JavaScript access and helping protect against XSS.
7️⃣ Email verification & password reset
Yes — we support secure password reset via email link and email OTP verification (6-digit code with 5-minute expiry). SMTP configuration is required per database.
8️⃣ Rate limiting / brute-force protection
Rate limiting is not built-in today but is on our near-term roadmap.
In the meantime, if you’re deploying behind services like Vercel, Cloudflare, or AWS, these platforms provide built-in rate limiting and DDoS protection that typically cover auth endpoints out of the box without additional setup.
Once we ship native rate limiting, it will work automatically without requiring deployment changes.
9️⃣ Session revocation / force logout
Yes — users can sign out to clear their session. Password changes can optionally revoke other active sessions, and deleting a user invalidates sessions.
🔟 Advanced roles / SSO (future)
The architecture is designed to be extensible. Google OAuth is already supported, and support for custom roles, SAML/SSO, and more advanced access models can be added as the platform evolves.