Opening proof path
SIRJ is loading the workspace, connector, or public page with the same proof path intact: ad spend, lead, booked job, invoice, paid.
Security/Account security and recovery
Review SIRJ email and Google access, signed OAuth state, scoped sessions, password recovery, reset-token handling, invited access, and redacted auth responses.
Access answers
Auth copy should make the next step obvious without exposing the credential or session details that belong inside the application.
SIRJ supports email and password signup, email and password login, Google signup, Google login, and invitation acceptance for client-scoped users. Each path creates or resumes a workspace session tied to account, user, role, client scope, and default client context.
The buyer can choose a familiar access method without wondering whether login, Google access, or client invitations create different product states.
Review related pathGoogle access uses signed OAuth state with purpose, provider, mode, nonce, optional account context, and redirect context before the callback creates or resumes the workspace session. Login mode rejects an unlinked Google identity instead of creating surprise access.
Google access is not a loose social login shortcut. It has to preserve the intended auth mode and match an existing identity before returning a user to the dashboard.
Review related pathThe forgot-password route requests a one-time reset path without exposing whether workspace data exists. The reset route requires a token and a new password, rejects incomplete or expired links, and sends the user back to login after the password changes.
Recovery gives the user a clean return path without revealing workspace, client, credential, or source data on public forms.
Review related pathNo. Invitation acceptance is separate from owner signup and uses account id, client id, invitation id, token, email, role, and password setup before issuing a client-scoped session. Invite records keep token hashes out of user-facing payloads.
A client reviewer can be brought into one workspace without accidentally inheriting the agency owner's workspace, billing, integration, or export authority.
Review related pathAuth paths
Owners, returning users, Google users, and invited clients should not have to guess which route matches their access state.
| Access path | User sees | Protected by |
|---|---|---|
| Email signup | Business name, account type, optional plan or source context, owner name, email, password, and a workspace route after account creation. | Passwords are hashed with scrypt before credential storage, password length is checked on the form action, and auth responses omit password hashes. |
| Email login | Email and password login, friendly failed-login copy, password recovery, and a direct dashboard route after a successful session is established. | Credential verification issues a fresh scoped session, ambiguous tenant email matches fail closed unless account scope is provided, and response payloads omit token hashes. |
| Google access | Google signup or login buttons on the auth pages, followed by the dashboard or a clear fallback back to login if completion fails. | OAuth state is HMAC signed, purpose-bound, mode-aware, nonce-bearing, and verified before session creation or identity reuse. |
| Client invitation | An invite-specific acceptance page with account, client, invite token, email, name, password setup, and a dashboard route after acceptance. | The invitation runtime checks token, account, client, role, expiry, and revocation before creating a scoped membership and session. |
Recovery states
Recovery paths need neutral user messaging, clear next steps, and no accidental workspace disclosure.
| State | User sees | Safeguard |
|---|---|---|
| Reset requested | A password reset request form that accepts an email and then shows a sent state without exposing workspace existence. | The server action calls the password reset request endpoint only when an email is present, then redirects to a neutral sent confirmation. |
| Reset link opened | A reset page that requires the token from the link and a new password before returning the user to login. | Incomplete tokens, short passwords, invalid tokens, and expired links return friendly route-level errors rather than creating a session. |
| Password updated | A login notice after the password is changed, so the next step is an explicit login with the new credential. | The reset confirmation flow does not silently preserve a prior session; it sends the user back through the normal login path. |
| Invite recovery | Invitation errors tell the invited user to request a new link when the link is incomplete, invalid, expired, or revoked. | Invitation acceptance requires the original token and scoped invite identifiers before client workspace membership can be created. |
Session controls
Every protected report, dashboard, source, and export starts with the current account, user, role, and client scope.
| Control | User-visible result | Protection |
|---|---|---|
| Scoped session claims | After signup, login, Google access, or invite acceptance, the user lands in the dashboard with account, role, client scope, and default-client context. | Session creation validates account id, user id, role, client ids, default client scope, token hash, expiration, and revocation state. |
| HTTP-only session cookie | The browser can return to protected workspace routes after successful auth without asking for credentials on every page view. | The app sets an HTTP-only, same-site session cookie with production secure mode and an expiration derived from the session payload. |
| Token-hash storage | Users receive a normal signed-in experience while stored session records avoid keeping the raw session token. | Session token hashes are HMAC SHA-256 digests bound to the session secret, and tests verify user-facing payloads omit stored session-token hashes. |
| JWT-compatible verification | API or service contexts can validate signed tenant claims when a JWT-style session token is used. | JWT verification checks algorithm, signature, expiration, not-before timing, issuer, audience, account, user, role, and client scope. |
Access workflow
The workflow keeps access tied to the user job: create, return, recover, accept an invitation, or continue into scoped reporting.
| Step | What happens | User-visible proof |
|---|---|---|
| Choose the right access route | Public CTAs should route owners toward signup, returning users toward login, invited users toward invite acceptance, and recovery users toward the reset path instead of blending every access job into one form. | Account setup, login, signup, forgot password, reset password, and invitation pages each show different fields and next-step copy. |
| Validate credential or OAuth state | Email access verifies the supplied credential against the stored password hash, while Google access verifies signed OAuth state and identity mode before the session is created or resumed. | Users get a clear success route or a friendly error without seeing credential internals, token hashes, or provider tokens. |
| Create a scoped session | Successful auth creates a session with account id, user id, role, client ids, optional default client id, expiry, and a stored token hash rather than broad unspecific workspace access. | Roles, permissions, client workspaces, and dashboard routing explain what the signed-in user is allowed to see. |
| Recover without leaking state | Password recovery and invite recovery use explicit reset or invite routes that fail closed when a token is missing, expired, invalid, revoked, or too weak to complete. | Forgot password, reset password, and invitation acceptance pages show neutral or corrective errors instead of exposing account records. |
| Keep access tied to reporting scope | The access layer matters because every dashboard, Ask Data answer, report, export, and weekly delivery surface depends on the current account, role, and client scope. | Client workspaces, roles, invitations, reports, and security pages connect account access to the reporting surfaces a user can safely reach. |
Proof standards
Buyers see the user-facing control without exposed hashes, provider tokens, or private implementation state.
Auth and session tests assert that credential hashes, session-token hashes, provider access tokens, refresh tokens, and similar secrets are absent from user-facing auth outcomes.
Roles, client ids, default client ids, account memberships, and client memberships are validated before sessions or invited access are accepted.
Reset and invitation flows require their expected token and context, return corrective errors, and route users back to request a new link or log in after completion.
The signed state payload carries mode and purpose, and login mode rejects unlinked Google identities rather than creating a new account by surprise.
FAQ
Yes. SIRJ supports Google and email access for signup and login, while invitation acceptance remains a separate route for client-scoped users.
The reset route shows a corrective error and asks the user to request a new link instead of creating a session or exposing workspace state.
No. Session records can store token hashes for verification, but auth outcomes and public pages avoid exposing stored session-token hashes or raw credential internals.
No. Client invitations are scoped to the invited account, client workspace, role, email, and token before the invited user receives workspace access.
Ready when the numbers need to hold up
Start with Growth, review security, or route client access through scoped invitations before reports are shared.