Auth & Roles
Auth & Roles
Every signed-in person starts as a user. Additional access is granted through roles, memberships, or approved applications.
Roles
| Role | Meaning | Main access |
|---|---|---|
| User | Default signed-in account. | Dashboard, Study, Chat, Circles, personal tools. |
| Instructor | Approved teaching profile. | Instructor dashboard, sessions, courses, certificates, payouts. |
| Organization | Workspace/group owner or member context. | Organization resources, members, courses, and permissions. |
| Admin | Platform operator. | Admin dashboards, approval queues, users, billing, infrastructure, XRouter settings. |
Instructor Gate
Instructor access must stay blocked until an application is approved. The flow is:
- User opens Become Instructor from Study.
- User completes the multi-step application.
- User accepts instructor rules and declaration.
- Admin reviews details, verification files, payout settings, and risk notes.
- Admin approves or rejects.
- Approved user receives instructor dashboard access.
Sensitive verification documents are admin-only. Never expose ID proof, address proof, tax details, or bank details publicly.
Organization Access
Organizations allow users and instructors to work inside shared learning contexts. Membership should control what courses, boards, resources, bookings, and admin panels are visible.
Admin Access
Admin pages must check permissions server-side. Hiding navigation is not enough. Any route that mutates users, payouts, providers, infrastructure, or instructor status must verify admin rights in the API handler.
External OAuth
OAuth providers are used for login, calendar connection, GitHub export, and channel integrations. Keep app-specific OAuth credentials separate when scopes differ, such as login Google credentials versus Google Calendar credentials.