Account access
Sign in, register, sign out, and review your Sotiras account and profile. Start here if you already know the procedure, or go back to the support docs index if you need a different topic.
I want this article
Read the current support note if you are already in the right procedure.
I want the docs index
Go back to the section list when you need a different article or category.
I want support context
Jump to support docs home when the question is broader than one article.
Markdown article
Source: content/support-docs/account/account-access.md
Objective
Use this guide for the first account access workflows in Sotiras: registration, sign in, sign out, the default dashboard, the account page, and the profile page.
Register
Registration creates the first user and starter workspace for an organization. The registering user becomes the initial workspace owner.
Required fields:
- Name
- Organization
- Username
- Password
After successful registration, Sotiras signs the user in and opens the default dashboard.
Use a username that the user can remember and that support can reference without exposing an email address in every workflow. Email remains important for contact, recovery, verification, invitations, and security notifications.
Sign in
Users sign in with their email address or username and password. If the credentials are not accepted, the sign-in page shows a generic error so account details are not leaked.
Some workspaces can require tenant SSO when an approved identity provider is configured. In that case, the sign-in page directs users to the workspace identity provider instead of accepting a password for that tenant.
Username and email handling
Sotiras accepts either username or email for the credentials flow. Email is stored as account contact information and is used for transactional notifications, verification, invitations, and password reset links.
Support teams should not confirm whether a username or email address exists. Use the password reset flow for self-service recovery and keep authentication failures generic.
Runtime app access
Runtime applications should be able to delegate common access routes to Sotiras when the tenant wants the Sotiras security framework to handle them. Candidate framework-owned routes include sign in, registration, sign out, account, profile, SSO callbacks, and OAuth/OIDC endpoints.
This reduces implementation work for runtime clients, but app-specific authorization still belongs to the application or to an explicit Sotiras authorization integration.
Sign out
Use the sign-out page to end the current browser session. Signing out redirects back to the sign-in page.
Dashboard
The dashboard is the default logged-in landing page. It confirms the current session, the primary workspace, tenant role, and links to the portal, support docs, account page, profile, and sign out.
Account
The account page summarizes account status, account creation date, primary workspace, primary role, password controls, two-factor authentication, passkey options, and current security controls. Two-factor changes send account security notifications when email is configured.
Profile
The profile page shows account status, email verification state, session details, and active tenant memberships. Tenant roles remain part of the Sotiras authorization model, not Auth.js internals.
Support notes
Account access support should avoid exposing whether a username or email address belongs to a real account. Authentication failures should remain generic. Use reset, verification, and invitation links instead of manual password handling.
Common support checks:
- Confirm the user is using the expected username or email for credentials sign-in.
- Confirm the user is on the expected tenant or callback route.
- Confirm the account is active and belongs to the intended workspace before changing access.
- Escalate suspected account takeover, repeated failed sign-ins, or unauthorized workspace access as an incident.