User Mapping

• Map yourUser existingTable: user table and columns to what SWAIN’s authentication layer expects.
• SpecifyIdentify which table holdsin your database stores user accountsaccounts.
• Map the key columns required for authentication: a unique ID column, an email (or username) column, and identifya keypassword column containing hashed passwords.
• Passwords must be stored hashed; SWAIN never requires plain‑text passwords.
• You can also map additional fields like name or profile attributes.
• Map Roles and Permissions (if using RBAC):
  • Define which tables represent roles and permissions and how they relate to users.
  • Map the relationships between users, roles, and permissions so the platform can enforce access control.
• Map Session / Refresh Tokens:
  • Provide a session table with columns such as userid, ID,userId, emailrefreshToken, expiresAt, and passwordlastUsed hash.to enable refresh token flows.
• OptionallyMap API Keys (optional, for server‑to‑server or SDK access):
  • Create an API keys table with columns like id, userId (or accountId), key, createdAt, and revokedAt (nullable).
  • Mapping this table enables issuing and revoking API keys for users or tenants.
• Map Social Profiles (optional):
  • If you enable social login, map fieldsa forsocial rolesprofile ortable permissionsthat iflinks youexternal planprovider IDs to useyour role-basedusers.
  access
  control.
• Accurate user mapping ensures thatSWAIN login,knows signuphow to read and tokenwrite generationuser‑related workdata correctlyfor withauthentication, yourauthorization, databasesession schema.management, and API key management.