@things-factory/auth-base 10.1.20 → 10.1.24

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@things-factory/auth-base",
-  "version": "10.1.20",
+  "version": "10.1.24",
   "main": "dist-server/index.js",
   "browser": "dist-client/index.js",
   "things-factory": true,
@@ -48,5 +48,5 @@
     "passport-jwt": "^4.0.0",
     "passport-local": "^1.0.0"
   },
-  "gitHead": "6bd01660a4b28554bbe6ae4ee58f3ff844c5af69"
+  "gitHead": "0d88a504e0ffa63cd91279b88c6998d4bf1b3d86"
 }

package/tests/appliance-revoke-db.test.ts

@@ -0,0 +1,249 @@
+/**
+ * `revokeApplianceCredential` — taking a device's access away while keeping the device.
+ *
+ * ── What was missing ────────────────────────────────────────────────────────
+ * There was no way to leave an appliance without a working credential. You could delete the
+ * row, which takes its history with it, or issue a new secret, which puts a **live** credential
+ * in the database and on the screen. Neither is revocation.
+ *
+ * ── Why the status is the switch, not the field ─────────────────────────────
+ * The access token is a signed JWT. Clearing `Appliance.accessToken` drops our copy and does
+ * nothing to the token already on the device — it keeps verifying against SECRET until its own
+ * `exp`, a year out. `User.checkAuth` is what refuses it, and it refuses on the shadow user's
+ * status. So these tests assert the status; the cleared fields are tidiness, and one case says
+ * so explicitly because the opposite is easy to assume.
+ *
+ * ⚠ sqlite (`tests/db.ts`). Enum columns fall to the varchar branch here, so this pins the
+ * value that is stored and read back, not the dialect's own enum behaviour.
+ */
+
+import { closeAuthDatabase, Domain, getRepository, openAuthDatabase, resetAuthDatabase } from './db'
+import { loadCompiled } from './compiled'
+
+const jwt = require('jsonwebtoken')
+
+const { Appliance } = loadCompiled('service/appliance/appliance')
+const { User, UserStatus } = loadCompiled('service/user/user')
+const { ApplianceMutation } = loadCompiled('service/appliance/appliance-mutation')
+
+const mutation = new ApplianceMutation()
+
+let domain: any
+let actor: any
+
+function context(d: any = domain) {
+  return { state: { domain: d, user: actor, tx: undefined }, throw: (code: number, message: string) => {
+    const error: any = new Error(message)
+    error.status = code
+    throw error
+  } } as any
+}
+
+async function shadowUserOf(applianceId: string) {
+  return await getRepository(User).findOneBy({ reference: applianceId, userType: 'appliance' })
+}
+
+async function makeAppliance(name: string) {
+  const appliance = await mutation.createAppliance(
+    { name, serialNo: `${name}-SN`, brand: 'Acme', model: 'X1' },
+    context()
+  )
+
+  /* Registering does not issue a token; the screen shows "not issued" until someone asks. */
+  return await mutation.generateApplianceSecret(appliance.id, context())
+}
+
+beforeAll(async () => {
+  await openAuthDatabase()
+})
+
+afterAll(async () => {
+  await closeAuthDatabase()
+})
+
+beforeEach(async () => {
+  await resetAuthDatabase()
+
+  domain = await getRepository(Domain).save({ name: 'acme', subdomain: 'acme' })
+  actor = await getRepository(User).save({
+    username: 'operator@acme.z',
+    email: 'operator@acme.z',
+    name: 'operator',
+    status: UserStatus.ACTIVATED,
+    domains: [domain]
+  })
+})
+
+describe('revoking an appliance credential', () => {
+  it('leaves the appliance, and leaves it with nothing to authenticate with', async () => {
+    const issued = await makeAppliance('gate-a')
+
+    expect(issued.accessToken).toBeTruthy()
+    expect((await shadowUserOf(issued.id))!.status).toEqual(UserStatus.ACTIVATED)
+
+    const revoked = await mutation.revokeApplianceCredential(issued.id, context())
+
+    /* The record survives — that is the whole difference from deleteAppliance. */
+    expect(revoked.id).toEqual(issued.id)
+    expect(revoked.name).toEqual('gate-a')
+    expect(await getRepository(Appliance).findOneBy({ id: issued.id })).toBeTruthy()
+
+    expect(revoked.accessToken).toBeNull()
+  })
+
+  it('turns the shadow user inactive — the switch every request reads', async () => {
+    /*
+     * ⚠ The case the feature exists for. `checkAuth` throws USER_NOT_ACTIVATED on INACTIVE, so
+     * this is what refuses the token that is already out on the device. Without it the cleared
+     * field means nothing: the JWT verifies on its signature alone.
+     */
+    const issued = await makeAppliance('gate-b')
+
+    await mutation.revokeApplianceCredential(issued.id, context())
+
+    const appuser = await shadowUserOf(issued.id)
+
+    expect(appuser).toBeTruthy()
+    expect(appuser!.status).toEqual(UserStatus.INACTIVE)
+  })
+
+  it('keeps the shadow user rather than deleting it', async () => {
+    /*
+     * `deleteAppliance` deletes it, and that is right when the appliance goes too. Here the
+     * appliance stays, so the identity has to stay with it — past rows point at it as creator
+     * and updater, and re-issuing keeps the same id rather than orphaning them.
+     */
+    const issued = await makeAppliance('gate-c')
+    const before = await shadowUserOf(issued.id)
+
+    await mutation.revokeApplianceCredential(issued.id, context())
+
+    const after = await shadowUserOf(issued.id)
+
+    expect(after).toBeTruthy()
+    expect(after!.id).toEqual(before!.id)
+  })
+
+  it('stops holding a copy of the credential it just killed', async () => {
+    /*
+     * Tidiness, not a control — and worth saying so, because the opposite is easy to believe.
+     * The JWT verifies on its signature, never against this column, so clearing it does not
+     * stop the token on the device. The status does that.
+     *
+     * ⚠ Which leaves a real hazard this does NOT close: put the status back to ACTIVATED
+     * without issuing a new secret and the old token authenticates again, cleared column or
+     * not. Nothing here prevents that. Closing it needs the token itself to be refusable —
+     * a jti denylist, or re-issuing as part of reactivation.
+     */
+    const issued = await makeAppliance('gate-d')
+
+    expect((await shadowUserOf(issued.id))!.password).toBeTruthy()
+
+    await mutation.revokeApplianceCredential(issued.id, context())
+
+    expect((await shadowUserOf(issued.id))!.password).toBeNull()
+  })
+
+  it('lets a new secret work afterwards', async () => {
+    /*
+     * A revoked appliance is INACTIVE, and `checkAuth` refuses that whatever the token says. So
+     * issuing again has to put the status back, or the new credential is dead on arrival — a
+     * failure that would look like the token being wrong.
+     */
+    const issued = await makeAppliance('gate-e')
+    await mutation.revokeApplianceCredential(issued.id, context())
+
+    const reissued = await mutation.generateApplianceSecret(issued.id, context())
+
+    expect(reissued.accessToken).toBeTruthy()
+
+    const appuser = await shadowUserOf(issued.id)
+
+    expect(appuser!.status).toEqual(UserStatus.ACTIVATED)
+    expect(appuser!.password).toEqual(reissued.accessToken)
+  })
+
+  it('⚠ hands back the very token it just revoked, when re-issued in the same second', async () => {
+    /*
+     * This pins a defect, not a guarantee. `Appliance.sign` puts `{ id, userType, appliance.id,
+     * status, domain.subdomain }` in the payload and nothing else — no jti, no nonce — and `iat`
+     * and `exp` are whole seconds. So two signings inside one second produce a byte-identical
+     * string, and "generate a new access token" returns the credential that was just revoked.
+     *
+     * It matters together with the hazard above: the status goes back to ACTIVATED on re-issue,
+     * and the token is the same one, so anything still holding the revoked token is back in.
+     * Revoking and immediately re-issuing — the obvious way to rotate a suspect device — is
+     * exactly the case where this bites.
+     *
+     * Closing it needs a per-issue claim in the payload (jti) that also gives the token
+     * something to be refused by. Until then this test says out loud what the product does.
+     */
+    const issued = await makeAppliance('gate-g')
+
+    await mutation.revokeApplianceCredential(issued.id, context())
+    const reissued = await mutation.generateApplianceSecret(issued.id, context())
+
+    expect(reissued.accessToken).toEqual(issued.accessToken)
+  })
+
+  it('refuses an appliance that belongs to another domain', async () => {
+    /*
+     * Revocation stops a device. Reaching across a tenant boundary with it would let one
+     * customer turn off another's equipment.
+     */
+    const issued = await makeAppliance('gate-f')
+    const stranger = await getRepository(Domain).save({ name: 'other', subdomain: 'other' })
+
+    await expect(mutation.revokeApplianceCredential(issued.id, context(stranger))).rejects.toThrow()
+
+    const appuser = await shadowUserOf(issued.id)
+
+    expect(appuser!.status).toEqual(UserStatus.ACTIVATED)
+  })
+})
+
+describe('what an already-issued token can still do', () => {
+  /*
+   * The token is a signed JWT. `checkAuth` is the only thing that looks at our records once the
+   * signature verifies, so these cases run the real token through the real function rather than
+   * reasoning about it.
+   */
+  function decode(token: string) {
+    return jwt.decode(token)
+  }
+
+  it('is refused while the appliance is revoked', async () => {
+    const issued = await makeAppliance('gate-h')
+
+    await expect(User.checkAuth(decode(issued.accessToken))).resolves.toBeTruthy()
+
+    await mutation.revokeApplianceCredential(issued.id, context())
+
+    await expect(User.checkAuth(decode(issued.accessToken))).rejects.toThrow()
+  })
+
+  it('⚠ works again the moment the status goes back, with no new secret issued', async () => {
+    /*
+     * This is the hazard, run rather than argued. Revocation lives entirely in the shadow user's
+     * status: the signature is still good, `exp` is a year out, and nothing consults the cleared
+     * `password` column. So putting the status back — by hand, by a future screen, by a fixture —
+     * restores every token that was ever issued to this appliance.
+     *
+     * Clearing the columns does not prevent it, and this test exists so nobody believes it does.
+     */
+    const issued = await makeAppliance('gate-i')
+    const oldToken = issued.accessToken
+
+    await mutation.revokeApplianceCredential(issued.id, context())
+    await expect(User.checkAuth(decode(oldToken))).rejects.toThrow()
+
+    const appuser = await shadowUserOf(issued.id)
+    await getRepository(User).save({ ...appuser, status: UserStatus.ACTIVATED })
+
+    const subject = await User.checkAuth(decode(oldToken))
+
+    expect(subject).toBeTruthy()
+    expect(subject.id).toEqual(appuser!.id)
+    expect(subject.password).toBeNull()
+  })
+})