Passwords are not stored as passwords
Daptin hashes credentials with bcrypt and compares them through the authentication path.
Daptin
Run Daptin →
Authentication
Give people a secure path from signup to an authenticated session, without turning identity plumbing into a second product.
Built in
Run signup, signin, email verification, password recovery, JWT sessions, and optional one-time-password verification against the same user and group model used by the rest of Daptin.
Daptin hashes credentials with bcrypt and compares them through the authentication path.
Authentication-version checks let password or account changes invalidate previously issued sessions.
Use TOTP enrollment and verification with bounded attempts and replay protection.
The authenticated user and group membership feed directly into record, relationship, and action permissions.
Account journeys
Enroll users, verify the identity path, recover passwords, and place people into the groups used by the application.
Use the same accounts for dashboard3 and product APIs while keeping administrator membership explicit.
Add TOTP with attempt limits and replay checks after defining a practical recovery path for lost authenticators.
Use Daptin authentication for its own clients, or let other registered apps obtain identity through the separate OAuth/OIDC provider.
What the server protects
Passwords are compared through bcrypt hashes. JWTs carry authenticated context into APIs and actions, while an authentication version ties issued sessions to the current account state so password and credential changes can invalidate older tokens.
Authentication establishes who is calling. It does not grant blanket access: table, row, relationship, and action permissions still decide what that identity may do.
Explore authorization →