Auth project
The wizard that creates your authentication tenant — five steps from name to live dashboard.
Creating an Authentication project in Eved provisions a tenant in the Febasi Auth service and opens a dashboard where you manage users, roles, permissions, sessions, and security policies — without touching the API. From the same project you can also integrate the Auth API into your application code.
The wizard
Five steps. None of them have a right answer for every team — pick what fits, you can change everything from the dashboard later (except tenantCode).
Tenant
| Field | Constraint |
|---|---|
tenantCode | 2–50 chars; starts with a letter; lowercase + digits + hyphens + underscores. Permanent — pick something stable. |
tenantName | 2–255 chars. Human-readable. |
The tenantCode is what your application sends in POST /login as tenantCode — it identifies your organization to the Auth service. The wizard pre-fills it from the project slug; override if needed.
Password policy
| Field | Default | Range / Meaning |
|---|---|---|
minLength | 8 | 6–128 characters. The floor under which passwords are rejected. |
requireUppercase | true | At least one A–Z. |
requireNumbers | true | At least one digit. |
requireSpecialChars | false | At least one non-alphanumeric character. |
The policy applies on every POST /register and on password updates. Failures return PASSWORD_POLICY_VIOLATION with a violations[] array so your app can show field-level feedback.
Tokens
| Field | Default | Meaning |
|---|---|---|
accessTokenExpiration | 15 min | How long an issued JWT is valid before requiring a refresh. |
refreshTokenExpiration | 7 days | How long a refresh token can sit before the user must re-authenticate. |
Shorter access tokens reduce blast radius on a stolen JWT. Longer refresh tokens give users a more forgiving session lifetime. The default 15-min / 7-day split is the conventional middle.
Session
| Field | Default | Effect |
|---|---|---|
maxConcurrentSessions | 5 | How many active refresh tokens a single user can hold. |
enforceLogout | false | At the limit: true rejects new logins with SESSION_LIMIT_EXCEEDED; false evicts the oldest session. |
sessionTimeout | 30 min | Inactivity window. Sessions idle longer than this are treated as expired. |
otpEnabled | false | Two-factor authentication. Schema reserved; not yet enforced. |
Review & create
A read-only summary of everything you entered. Submitting calls the Febasi Auth service, creates the tenant, seeds the default super_admin role, and returns you to the project's dashboard.
If the call fails, the project is created in error status with the failure reason captured. Fix the value (most often a duplicate tenantCode) and retry from the project settings.
What you get afterwards
The project page becomes your Auth dashboard with five tabs:
| Tab | What it does |
|---|---|
| Users | Create, list, edit, delete users. Reset tokens for a specific user. Visible password-policy hints inline. |
| Roles | Define hierarchy levels, attach permissions, assign roles to users. |
| Permissions | The system catalog plus any custom scope:action permissions you create. |
| Tokens | Active refresh tokens. Revoke a single one, all for a user, or tenant-wide. |
| Settings | Password policy, token expiration, session limits, JWT secret rotation, CORS, IP allowlist. |
Everything here also has an Auth API endpoint so you can automate from your application — the dashboard is the visual surface, the API is the programmatic one.
What's next
Auth → Getting started
Use the new tenant from your application — log in, hold an access token, call /me.
Auth → Registration
Pick how new users will be created: from this dashboard, from your admin UI, or from a public signup page.
Auth → Roles & permissions
Model your access-control hierarchy.
Heads-up
The tenantCode is permanent. Everything else — password policy, token lifetimes, session limits, OTP toggle, CORS, IP allowlist — is editable from the Settings tab without affecting active sessions retroactively.