@plitzi/sdk-server 0.33.2 → 0.34.1

package/dist/core/auth/api.d.ts

@@ -1,6 +1,7 @@
 import { CredentialCarrier } from './credentials';
+import { Csrf } from './csrf';
 import { Actor, Identity } from './identity';
-import { Tokens } from './tokens';
+import { AuthFailure, Tokens } from './tokens';
 import { SSRSession } from '@plitzi/sdk-shared';
 /**
  * An account, as whatever stores accounts reports one. Deliberately not a user model: these are the only fields any
@@ -18,11 +19,81 @@ export interface AccountRecord {
     passwordHash?: string;
     /** Unix seconds, for the refresh credential this account currently holds. */
     refreshExpiresAt?: number;
+    /**
+     * Unix seconds the session being renewed BEGAN, for `lifetimes.session` — the cap on how long one may live
+     * however often it renews. Only `findByRefreshToken` needs to report it, and only a deployment that sets a cap.
+     *
+     * The renewal window is already an idle timeout: a session nobody refreshes dies with its refresh token. This is
+     * the other half, and without it a session that renews quietly renews forever.
+     */
+    sessionStartedAt?: number;
 }
 export interface AccountAccess {
     roles: string[];
     permissions: string[];
 }
+/** What a session was created from, so a "your devices" list can name it. */
+export interface SessionClient {
+    userAgent?: string;
+    ip?: string;
+}
+/**
+ * What an account is allowed to be. `inactive` is the account's own doing (deactivated, never confirmed);
+ * `blocked` is the deployment's. Neither may hold a session — the distinction is for whoever has to explain it.
+ */
+export type AccountStatus = 'active' | 'inactive' | 'blocked';
+/** One live session, as its owner may see it. Never the credential itself. */
+export interface SessionSummary {
+    id: number;
+    userAgent?: string;
+    ip?: string;
+    createdAt: number;
+    expiresAt: number;
+    /** The session asking. A device list without it invites someone to revoke the one they are using. */
+    current: boolean;
+}
+/** A second factor as the store keeps it. `secret` is the TOTP seed; `recoveryCodes` are already hashed. */
+export interface MfaRecord {
+    secret: string;
+    /** Unix seconds the enrolment was proven with a real code. Absent means started and never finished. */
+    confirmedAt?: number;
+    recoveryCodes?: string[];
+}
+/** Something worth writing down. Fed to an audit log, a webhook, a SIEM — whatever the deployment has. */
+export interface SecurityEvent {
+    type: 'login' | 'login.failed' | 'login.mfa-required' | 'logout' | 'signup' | 'password.changed' | 'password.reset' | 'profile.changed' | 'email.changed' | 'account.deleted' | 'session.revoked' | 'mfa.enabled' | 'mfa.disabled' | 'mfa.failed' | 'admin.status-changed' | 'admin.roles-changed' | 'admin.account-deleted' | 'admin.impersonated';
+    /** Who it happened to. Absent when the attempt named nobody that exists. */
+    userId?: number;
+    /** Who did it, when that is somebody else — an administrator acting on an account. */
+    actorId?: number;
+    at: number;
+    detail?: Record<string, unknown>;
+    carrier?: CredentialCarrier;
+}
+export interface AccountQuery {
+    /** Matched against username and email. */
+    search?: string;
+    status?: AccountStatus;
+    limit?: number;
+    offset?: number;
+}
+/**
+ * Why a session is being written — which is not something the pair itself can say, and the difference matters to
+ * any store that keeps more than one session per account.
+ *
+ * A sign-in creates a session. A renewal **replaces one**, and a store that cannot tell them apart grows a row per
+ * renewal: a device list that fills with ghosts of the same browser, and a revoked session that comes back because
+ * the row it was meant to overwrite is still there. A store that keeps a single pair on the account row ignores
+ * this and overwrites either way, which is what it always did.
+ */
+export interface SessionContext {
+    /** The credential being renewed. Absent for a fresh sign-in. */
+    replaces?: {
+        refreshToken?: string;
+        accessToken?: string;
+    };
+    client?: SessionClient;
+}
 /**
  * The account store, as auth needs to see it. Every method is optional except the three the session cycle cannot do
  * without, and **what is absent decides what this server offers**: a deployment with no `createAccount` has no
@@ -30,8 +101,14 @@ export interface AccountAccess {
  * deployment with its own user table and one that signs everybody in through an external provider.
  */
 export interface AccountAdapters {
-    /** Persist a freshly minted pair. Storing it is what retires the previous one — the whole of rotation. */
-    saveSession: (userId: number, session: SSRSession) => Promise<void>;
+    /**
+     * Persist a freshly minted pair.
+     *
+     * `context` says whether this is a new session or one replacing another — see {@link SessionContext}. A store
+     * with one pair per account may ignore it and overwrite; a store with a `session` table must not, or every
+     * renewal leaves a row behind.
+     */
+    saveSession: (userId: number, session: SSRSession, context?: SessionContext) => Promise<void>;
     /** Clear the pair, by whichever half the caller holds, or by account. */
     clearSession: (target: {
         accessToken?: string;
@@ -40,6 +117,40 @@ export interface AccountAdapters {
     }) => Promise<void>;
     /** Global roles and permissions, for the body a grant answers with. */
     loadAccess: (userId: number) => Promise<AccountAccess>;
+    /** By id. Needed wherever a flow acts on the account already signed in — changing a password, deleting itself. */
+    findById?: (userId: number) => Promise<AccountRecord | undefined>;
+    /**
+     * Change what an account says about itself. Only the keys present are touched — an absent `email` means "leave
+     * it", never "clear it", which is what an implementation writing every column unconditionally would do.
+     */
+    updateAccount?: (userId: number, changes: {
+        username?: string;
+        email?: string;
+    }) => Promise<AccountRecord>;
+    /**
+     * Suspend, block or restore. Separate from `deleteAccount` because they are different acts with different
+     * consequences: a suspension is reversible and keeps everything the account made.
+     */
+    setStatus?: (userId: number, status: AccountStatus) => Promise<void>;
+    /**
+     * Erase the account. Whether that means deleting a row or anonymising one is the deployment's call and it is a
+     * real one — content, audit logs and invoices usually have to outlive the person. Either way it must end every
+     * session, which deleting the account's sessions does.
+     */
+    deleteAccount?: (userId: number) => Promise<void>;
+    /** Page through accounts, for an administrator. `total` is the count before the page was taken. */
+    listAccounts?: (query: AccountQuery) => Promise<{
+        accounts: AccountRecord[];
+        total: number;
+    }>;
+    /** Replace an account's global roles with exactly these. */
+    setRoles?: (userId: number, roles: string[]) => Promise<void>;
+    /** The account's live sessions. `currentToken` marks the one asking, so a device list can say "this device". */
+    listSessions?: (userId: number, currentToken?: string) => Promise<SessionSummary[]>;
+    /** End one session. Scoped by account: a session id from another account must not resolve. */
+    revokeSession?: (userId: number, sessionId: number) => Promise<boolean>;
+    /** End every session except the one asking. */
+    revokeOtherSessions?: (userId: number, currentToken: string) => Promise<number>;
     findByUsername?: (username: string) => Promise<AccountRecord | undefined>;
     findByRefreshToken?: (token: string) => Promise<AccountRecord | undefined>;
     createAccount?: (account: {
@@ -53,7 +164,51 @@ export interface AccountAdapters {
     findByResetToken?: (token: string) => Promise<AccountRecord | undefined>;
     setValidationToken?: (userId: number, token: string) => Promise<void>;
     findByValidationToken?: (token: string) => Promise<AccountRecord | undefined>;
-    markVerified?: (userId: number) => Promise<void>;
+    /**
+     * Park an address the account asked to move to, with the token that will confirm it. It is NOT the account's
+     * address yet, and nothing may sign in with it — the whole point is that the old one keeps working until the new
+     * one is proven, so a typo is a nuisance instead of a lockout.
+     *
+     * Supplying these three (with `sendMail`) is what turns an email change into a confirmed one. A deployment that
+     * leaves them out changes the address on the spot, which is the simpler thing and a legitimate choice.
+     */
+    setPendingEmail?: (userId: number, email: string, token: string) => Promise<void>;
+    /** The account waiting on this confirmation, and the address it is waiting for. */
+    findByPendingEmail?: (token: string) => Promise<{
+        account: AccountRecord;
+        email: string;
+    } | undefined>;
+    /** Forget the parked address — it was confirmed, superseded, or the account was closed. */
+    clearPendingEmail?: (userId: number) => Promise<void>;
+    /**
+     * Confirm or un-confirm the address. Both directions from one adapter, because changing an email has to be able
+     * to take verification away — a `markVerified` that only ever set it made that impossible to express.
+     */
+    setVerified?: (userId: number, verified: boolean) => Promise<void>;
+    /**
+     * A one-time code, hashed. `purpose` separates a sign-in link from anything else that uses the same table, and
+     * `identifier` is what it was issued against — an email address, usually.
+     */
+    saveOtp?: (code: {
+        purpose: string;
+        identifier: string;
+        codeHash: string;
+        expiresAt: number;
+        userId?: number;
+    }) => Promise<void>;
+    /** The live code for this purpose and identifier, if there is one. Expired rows may be returned or not. */
+    findOtp?: (purpose: string, identifier: string) => Promise<{
+        id: number;
+        codeHash: string;
+        expiresAt: number;
+        userId?: number;
+    } | undefined>;
+    /** Spend it. Deleting rather than flagging: a spent code that still exists is one a lookup can forget to exclude. */
+    consumeOtp?: (id: number) => Promise<void>;
+    /** The second factor for this account, if it has one. Without it, no MFA is offered at all. */
+    loadMfa?: (userId: number) => Promise<MfaRecord | undefined>;
+    saveMfa?: (userId: number, record: MfaRecord) => Promise<void>;
+    deleteMfa?: (userId: number) => Promise<void>;
     /** Called for validation and password-reset mail. Without it neither flow is offered. */
     sendMail?: (message: {
         to: string;
@@ -70,15 +225,110 @@ export interface AccountAdapters {
         status?: number;
     } | undefined>;
 }
+/** What a flow was asked to do, for the throttle below. */
+export type ThrottledAction = 'login' | 'signup' | 'forgotPassword' | 'resetPassword' | 'changePassword' | 'exchange' | 'mfa' | 'passwordless';
+export interface ThrottleAttempt {
+    action: ThrottledAction;
+    /** What is being attempted against — a username, an email, a token. Never a password. */
+    key: string;
+    carrier?: CredentialCarrier;
+    /**
+     * Not a question but a report: this one worked, so whatever was counted against the key can be forgotten. The
+     * return value is ignored.
+     *
+     * It matters because the check happens BEFORE the password is examined — which is what makes a throttled attempt
+     * cost no hash — so without this the counter cannot tell ten failures from ten sign-ins. An app that signs the
+     * same account in repeatedly would lock it out by succeeding. A limiter that ignores this is simply stricter.
+     */
+    succeeded?: boolean;
+}
+export interface PasswordPolicy {
+    /**
+     * Default 8, which is NIST SP 800-63B's floor. There are deliberately no composition rules: requiring a digit
+     * and a symbol measurably produces `Password1!` and nothing safer.
+     */
+    minLength?: number;
+    /** Anything else this deployment decides — a breach-list lookup, a strength estimator. Return why, or nothing. */
+    validate?: (password: string, context: {
+        username?: string;
+        email?: string;
+    }) => Promise<string | undefined>;
+}
 export interface AuthApiConfig {
-    /** Compare a password against a stored hash. A deployment picks its own algorithm; nothing here assumes one. */
+    /**
+     * How passwords are hashed and checked. **Defaults to scrypt from the standard library**, so a deployment that
+     * has no opinion does not have to have one — and, more to the point, cannot end up with password login quietly
+     * switched off because it did not supply a function it had no reason to know about.
+     *
+     * Supply both to keep an existing algorithm: a store full of bcrypt hashes needs bcrypt.
+     */
     verifyPassword?: (plain: string, hash: string) => Promise<boolean>;
     hashPassword?: (plain: string) => Promise<string>;
-    /** Opaque, single-use strings for validation and reset links. */
+    /** Opaque, single-use strings for validation and reset links. Defaults to 128 random bits, hex. */
     generateToken?: () => string;
     /** Whether a new account may sign in immediately or has to confirm its address first. */
     verifyOnSignup?: boolean;
+    /**
+     * The global capability an administrator must hold to act on somebody else's account. Named rather than fixed,
+     * because what a deployment calls its permissions is its own vocabulary. Default `userManage`.
+     */
+    adminPermission?: string;
+    /**
+     * The capability that lets somebody obtain a session AS another account, and the switch that offers the flow at
+     * all: **absent, there is no impersonation** and `/auth/admin/impersonate` answers 404.
+     *
+     * Deliberately its own permission rather than part of `adminPermission`. Support staff who can suspend an account
+     * and support staff who can become one are not the same grant, and defaulting the second to the first would hand
+     * it out to everybody who already had the first — a power that appears from an upgrade nobody read.
+     */
+    impersonationPermission?: string;
+    /** What a password has to be. Applied wherever one is set: signing up, resetting, changing. */
+    password?: PasswordPolicy;
+    /**
+     * May this attempt proceed? Answered **in memory by default**, so no deployment is unthrottled by omission.
+     *
+     * There used to be no default, on the reasoning that where the counter lives is a deployment decision. It is —
+     * but the consequence of leaving it out was that the ordinary deployment shipped an unmetered password oracle,
+     * because nobody configures an option they have not read about. The counting is per process; supply this to put
+     * one counter behind the whole fleet, which is what a cluster wants.
+     *
+     * A refusal is a 429 with `retryAfter`, raised before any password is checked so it costs no hash.
+     */
+    rateLimit?: (attempt: ThrottleAttempt) => Promise<boolean | {
+        allowed: boolean;
+        retryAfter?: number;
+    }>;
+    /** Where a failed delivery is reported. Defaults to `console.error`; it is never thrown — see `deliver`. */
+    onMailError?: (error: unknown, message: {
+        to: string;
+        template: string;
+    }) => void;
+    /**
+     * Every act worth recording, as it happens.
+     *
+     * An audit trail, a webhook, an alert on ten failed sign-ins — all the same feed, and none of them something the
+     * server should decide the shape of. Never awaited and never allowed to fail a request: a logging outage must
+     * not become an authentication outage.
+     */
+    onEvent?: (event: SecurityEvent) => void;
+    /** What an authenticator app calls this deployment when somebody enrols. Defaults to the token issuer. */
+    mfaIssuer?: string;
+    /** Set by `createAuth`, so `GET /auth/csrf` can mint one. Nothing here enforces the check — the routes do. */
+    csrf?: Csrf;
 }
+/** What an exchange came to, before it is turned into either an HTTP body or a rendered page's session. */
+export type ExchangeResult = {
+    ok: true;
+    account: AccountRecord;
+    access: AccountAccess;
+    session: SSRSession;
+} | {
+    ok: false;
+    offered: boolean;
+    status: number;
+    error: string;
+    reason?: AuthFailure;
+};
 /** What a handler answers: a body, and optionally what should happen to the session cookies. */
 export type AuthOutcome = {
     ok: true;
@@ -86,10 +336,19 @@ export type AuthOutcome = {
     body: object;
     session?: SSRSession;
     endSession?: boolean;
-} | {
+    csrf?: string;
+}
+/**
+ * `endSession` on a REFUSAL is not a contradiction: it is how a flow says "what this browser is holding is
+ * dead, stop holding it". Without it the cookies survive the refusal that proved them worthless, and the
+ * readable hint — which outlives the access token on purpose, to advertise the renewal window — sends the page
+ * back to renew on every single load. One 401 per page view, forever, for a session that ended weeks ago.
+ */
+ | {
     ok: false;
     status: number;
     body: object;
+    endSession?: boolean;
 };
 /**
  * The HTTP surface of authentication, as functions rather than routes.
@@ -112,6 +371,17 @@ export declare const createAuthApi: ({ tokens, identity, adapters, config }: {
         passwordReset: boolean;
         emailVerification: boolean;
         exchange: boolean;
+        mfa: boolean;
+        passwordless: boolean;
+        profile: boolean;
+        passwordChange: boolean;
+        accountDeletion: boolean;
+        sessionList: boolean;
+        administration: boolean;
+        /** Changing an address by confirming it, rather than on the spot. Needs somewhere to park it and a way to write. */
+        emailChange: boolean;
+        /** Off unless the deployment named the capability it takes — see `impersonationPermission`. */
+        impersonation: boolean;
     };
     /** What a client reads to know which of the flows below actually exist here. */
     describe: () => AuthOutcome;
@@ -121,8 +391,39 @@ export declare const createAuthApi: ({ tokens, identity, adapters, config }: {
      * signed-out from the refusal itself. It costs no query: the actor was resolved before routing.
      */
     session: (actor?: Actor) => AuthOutcome;
-    login: (credentials: Record<string, unknown>) => Promise<AuthOutcome>;
-    refresh: (refreshToken?: string) => Promise<AuthOutcome>;
+    login: (credentials: Record<string, unknown>, carrier?: CredentialCarrier) => Promise<AuthOutcome>;
+    /**
+     * The second half of a sign-in that owed a factor.
+     *
+     * Takes a TOTP code or a recovery code. A recovery code is SPENT — removed from the stored list — because one
+     * that survives being used is a password with extra steps.
+     */
+    completeMfa: (mfaToken: string, code: string, carrier?: CredentialCarrier) => Promise<AuthOutcome>;
+    /**
+     * Signing in with a code sent to an email address, and no password at all.
+     *
+     * Two decisions worth stating. **The request answers the same whether the address exists or not** — anything
+     * else turns this endpoint into a way to ask which addresses have accounts. And **it never creates an
+     * account**: a sign-in flow that silently registers whoever asks is a different feature, and one a deployment
+     * should choose deliberately rather than inherit.
+     */
+    passwordless: {
+        request: (email: string, carrier?: CredentialCarrier) => Promise<AuthOutcome>;
+        complete: (email: string, code: string, carrier?: CredentialCarrier) => Promise<AuthOutcome>;
+    };
+    /**
+     * Everything about this account's second factor. `begin` hands back a secret and the URI an app scans; nothing
+     * is in force until `confirm` proves a code from it.
+     */
+    mfa: {
+        status: (actor: Actor | undefined) => Promise<AuthOutcome>;
+        begin: (actor: Actor | undefined) => Promise<AuthOutcome>;
+        /** Proves the app was actually set up, and only then does the factor start being required. */
+        confirm: (actor: Actor | undefined, code: string) => Promise<AuthOutcome>;
+        /** Removing a factor is a security downgrade, so it asks for the password the way deleting an account does. */
+        disable: (actor: Actor | undefined, password?: string) => Promise<AuthOutcome>;
+    };
+    refresh: (refreshToken?: string, carrier?: CredentialCarrier) => Promise<AuthOutcome>;
     /** Reachable with an expired access token on purpose, or a live refresh token could never be revoked. */
     logout: (credentials: {
         accessToken?: string;
@@ -135,14 +436,102 @@ export declare const createAuthApi: ({ tokens, identity, adapters, config }: {
      */
     revokeSessions: (userId?: number) => Promise<AuthOutcome>;
     exchange: (provider: string, token: string, carrier: CredentialCarrier) => Promise<AuthOutcome>;
+    /**
+     * The same exchange, answering in accounts rather than in HTTP.
+     *
+     * A page server needs who came back and the session they got; the flow above needs a body and a status. They
+     * are the same act, and the translation between them has one correct answer — so it is made once, here, rather
+     * than by every deployment that wires an external identity provider into a rendered page.
+     */
+    exchangeAccount: (provider: string, token: string, carrier: CredentialCarrier) => Promise<ExchangeResult>;
     signup: (fields: Record<string, unknown>) => Promise<AuthOutcome>;
     /** Answers the same either way: whether an address has an account here is not something a stranger may probe. */
     forgotPassword: (email: string) => Promise<AuthOutcome>;
     resetPassword: (token: string, password: string) => Promise<AuthOutcome>;
     validateAccount: (token: string) => Promise<AuthOutcome>;
-    resendVerification: (email: string) => Promise<AuthOutcome>;
+    resendVerification: (email: string, redirect?: string) => Promise<AuthOutcome>;
+    /**
+     * Change what an account says about itself.
+     *
+     * Both fields are sign-in identifiers, so both are checked for collision first — a store that only has a unique
+     * index reports the clash as a driver error five hundred lines away.
+     */
+    updateProfile: (actor: Actor | undefined, fields: Record<string, unknown>) => Promise<AuthOutcome>;
+    /**
+     * Takes the parked address, having proved somebody reads it.
+     *
+     * Public, and it has to be: the link is opened from a mail client, in whatever browser that happens to be, with
+     * no session. The token is the whole credential — which is why it is single-use and why confirming also marks
+     * the account verified: an address that answered a link is an address that was proven.
+     */
+    confirmEmailChange: (token: string) => Promise<AuthOutcome>;
+    /**
+     * Change a password, having proved you know the current one.
+     *
+     * Then **every other session ends**. Changing a password is what somebody does when they think a credential
+     * escaped, and one that leaves the other sessions signed in has not done the thing they asked for. The session
+     * making the change survives, or the act of securing the account would sign them out of it.
+     */
+    changePassword: (actor: Actor | undefined, currentPassword: string, newPassword: string) => Promise<AuthOutcome>;
+    /**
+     * Close the account.
+     *
+     * Confirmed with the password when there is one — this is irreversible, and a borrowed session should not be
+     * able to do it. An account with no password (one that signs in through a provider) cannot be asked, so the
+     * session alone has to be enough.
+     */
+    deleteSelf: (actor: Actor | undefined, password?: string) => Promise<AuthOutcome>;
+    /** The devices this account is signed in on, with the one asking marked. */
+    listSessions: (actor: Actor | undefined) => Promise<AuthOutcome>;
+    /** End one of them. Scoped to the caller's own account, or a session id would be an IDOR. */
+    revokeSession: (actor: Actor | undefined, sessionId: number) => Promise<AuthOutcome>;
+    /** "Sign out everywhere else" — the thing to do from a device you still hold after losing one you do not. */
+    revokeOtherSessions: (actor: Actor | undefined) => Promise<AuthOutcome>;
+    admin: {
+        list: (actor: Actor | undefined, query: AccountQuery) => Promise<AuthOutcome>;
+        get: (actor: Actor | undefined, userId: number) => Promise<AuthOutcome>;
+        /**
+         * Suspend, block or restore an account — and **end its sessions when it stops being active**.
+         *
+         * That second half is the whole point. A ban that leaves the credential working is not a ban, it is a note
+         * in a database; the person stays signed in until their token happens to lapse.
+         */
+        setStatus: (actor: Actor | undefined, userId: number, status: AccountStatus) => Promise<AuthOutcome>;
+        setRoles: (actor: Actor | undefined, userId: number, roles: unknown) => Promise<AuthOutcome>;
+        remove: (actor: Actor | undefined, userId: number) => Promise<AuthOutcome>;
+        /**
+         * A session AS somebody else, for support that has to see what they see.
+         *
+         * Three properties make it something a deployment can live with, and all three are deliberate:
+         *
+         * - **It says so.** The credential carries `act` (RFC 8693), so every request made with it can be told from
+         *   one the account holder made — `Actor.impersonatedBy` is that claim, read back. A borrowed session that
+         *   is indistinguishable from a real one turns an audit log into fiction.
+         * - **It is short and cannot renew.** Fifteen minutes by default and no refresh token, so it expires rather
+         *   than becoming a permanent second key to somebody's account.
+         * - **It is off unless asked for**, behind its own permission — see `impersonationPermission`.
+         *
+         * The session is answered in the BODY and no cookie is written. Swapping the administrator's own session
+         * cookie for this one would sign them out of the account they administer from, and getting back would mean
+         * signing in again; whoever asked decides where to put a credential they were handed.
+         *
+         * One caveat a deployment has to know: a store that keeps a single session per account — no `session` table —
+         * will overwrite the subject's own session with this one, signing them out. Anything with per-session rows,
+         * which is what `createMysqlStore` builds, does not.
+         */
+        impersonate: (actor: Actor | undefined, userId: number, carrier?: CredentialCarrier) => Promise<AuthOutcome>;
+    };
+    /**
+     * A CSRF token for whoever is asking, bound to their session when they have one. Answered as a body AND as the
+     * cookie the binding writes, so a page can take whichever it finds easier to read.
+     */
+    issueCsrf: (sessionToken?: string) => AuthOutcome;
     /** Exposed so a deployment can mint a session outside the flows above — a rendered page's login form. */
-    issueSession: (userId: number) => Promise<SSRSession>;
+    issueSession: (userId: number, context?: SessionContext, options?: {
+        actingAs?: number;
+        ttlSeconds?: number;
+        renewable?: boolean;
+    }) => Promise<SSRSession>;
     resolveActor: (carrier: CredentialCarrier) => Promise<import('./identity').ActorResult>;
 };
 export type AuthApi = ReturnType<typeof createAuthApi>;