Authentication & SSO
Jutsu authenticates users with either a local email/password account or Google single sign-on, then issues a signed session token that the API checks on every request.
Sign-in methods
Each user account records the provider it was created with, so a given user signs in one consistent way.
| Method | How it works |
|---|---|
| Email & password | The user registers with an email and password. The password is stored hashed, never in plaintext. |
| Google SSO | The user authenticates with Google (OAuth). Jutsu links the Google identity to the account and no password is stored. |
New accounts complete email verification before they gain access, and a deactivated account is rejected even if it still holds a valid token.
Password reset
Local accounts support self-service password reset. Jutsu issues a one-time reset token with an explicit expiry; the token is accepted only before it expires, and a successful reset clears it. The same pattern applies to email-verification tokens and organization invitations — every such token carries an expiry rather than living indefinitely.
Sessions
After a successful sign-in, Jutsu issues a JSON Web Token (JWT) that the client sends as a bearer token:
Authorization: Bearer <token>- Algorithm. Tokens are signed with HS256 using a per-deployment secret. The API pins the verification algorithm to HS256 so a token cannot be accepted under a weaker scheme.
- Claims. The token carries the user identity (subject, email, name) plus issued-at and expiration timestamps.
- Lifetime. Tokens are short-lived relative to a long-running session and expire after a configurable window (a multi-day default). An expired or malformed token is rejected with
401. - Verification. On each request the API verifies the signature and expiry, then loads the current user — so disabling an account or changing its state takes effect without waiting for the token to lapse.
The exact token lifetime and signing secret are set per deployment via environment configuration. Confirm the configured lifetime and rotation policy against your deployment.
Organization scoping
A user can belong to more than one organization. Authentication establishes who you are; the request's organization context establishes which tenant you are acting in. The API resolves an organization for the session and evaluates every data access within that boundary, so a valid token alone never grants cross-organization access.