@things-factory/auth-base 10.1.31 → 10.1.33

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

@@ -17,6 +17,8 @@
  * value that is stored and read back, not the dialect's own enum behaviour.
  */
 
+import { config } from '@things-factory/env'
+
 import { closeAuthDatabase, Domain, getRepository, openAuthDatabase, resetAuthDatabase } from './db'
 import { loadCompiled } from './compiled'
 
@@ -32,11 +34,14 @@ 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
+  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) {
@@ -53,11 +58,25 @@ async function makeAppliance(name: string) {
   return await mutation.generateApplianceSecret(appliance.id, context())
 }
 
+/*
+ * Revocation is off unless the installation asks for it (ADR-0085 decision 2), so these cases
+ * turn it on. `credential-features.ts` reads the config on each call, which is what lets a test
+ * stand in for a configured installation.
+ *
+ * `credential-features-off.test.ts` holds the other side — what an installation that configures
+ * nothing sees.
+ */
+const configGet = config.get
+
 beforeAll(async () => {
+  config.get = ((key: string, fallback?: any) =>
+    key === 'credential/revocable' ? true : configGet(key, fallback)) as typeof config.get
+
   await openAuthDatabase()
 })
 
 afterAll(async () => {
+  config.get = configGet
   await closeAuthDatabase()
 })
 
@@ -107,6 +126,31 @@ describe('revoking an appliance credential', () => {
     expect(appuser!.status).toEqual(UserStatus.INACTIVE)
   })
 
+  it('moves the credential serial, which is what a status alone cannot do', async () => {
+    /*
+     * ⚠ The serial is the half of revocation that cannot be undone by putting the status back.
+     * Its effect shows up in `checkAuth` (ADR-0085 decision 4), so until that lands nothing else
+     * here would notice if the bump went missing — this case watches the column directly.
+     */
+    const issued = await makeAppliance('gate-s')
+    const before = (await shadowUserOf(issued.id))!.credentialSerial
+
+    expect(before).toEqual(1)
+
+    await mutation.revokeApplianceCredential(issued.id, context())
+
+    expect((await shadowUserOf(issued.id))!.credentialSerial).toEqual(before + 1)
+  })
+
+  it('moves it again on the next issue, so no generation is reused', async () => {
+    const issued = await makeAppliance('gate-t')
+
+    await mutation.revokeApplianceCredential(issued.id, context())
+    await mutation.generateApplianceSecret(issued.id, context())
+
+    expect((await shadowUserOf(issued.id))!.credentialSerial).toEqual(3)
+  })
+
   it('keeps the shadow user rather than deleting it', async () => {
     /*
      * `deleteAppliance` deletes it, and that is right when the appliance goes too. Here the
@@ -163,27 +207,26 @@ describe('revoking an appliance credential', () => {
     expect(appuser!.password).toEqual(reissued.accessToken)
   })
 
-  it('⚠ hands back the very token it just revoked, when re-issued in the same second', async () => {
+  it('does not hand back the token it just revoked, even 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.
+     * This used to pin a defect. The payload carried `{ id, userType, appliance.id, status,
+     * domain.subdomain }` and nothing else, and `iat` counts whole seconds, so two signings
+     * inside one second produced a byte-identical string — revoking and immediately re-issuing,
+     * which is the obvious way to rotate a suspect device, handed back the credential 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.
+     * The credential serial closes it: it moves on every issue and every revoke, and it is in
+     * the payload, so no two issues can produce the same token.
      */
     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)
+    expect(reissued.accessToken).not.toEqual(issued.accessToken)
+
+    /* And the reason is the serial, not the clock — the two tokens name different generations. */
+    expect(jwt.decode(reissued.accessToken).cs).toBeGreaterThan(jwt.decode(issued.accessToken).cs)
   })
 
   it('refuses an appliance that belongs to another domain', async () => {
@@ -222,14 +265,15 @@ describe('what an already-issued token can still do', () => {
     await expect(User.checkAuth(decode(issued.accessToken))).rejects.toThrow()
   })
 
-  it('⚠ works again the moment the status goes back, with no new secret issued', async () => {
+  it('stays refused when the status goes back, because the serial moved', 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.
+     * This used to pin a hazard. Revocation lived entirely in the shadow user's status, so
+     * putting the status back — by hand, by a fixture, by some future screen — let every token
+     * ever issued to that appliance work again. Clearing the stored copy did not help: the JWT
+     * verifies on its signature and never against that column.
      *
-     * Clearing the columns does not prevent it, and this test exists so nobody believes it does.
+     * The serial closes it. It moved on revoke and does not move back, so the old token names a
+     * generation this subject has left. Access can only come from issuing a new one.
      */
     const issued = await makeAppliance('gate-i')
     const oldToken = issued.accessToken
@@ -240,10 +284,11 @@ describe('what an already-issued token can still do', () => {
     const appuser = await shadowUserOf(issued.id)
     await getRepository(User).save({ ...appuser, status: UserStatus.ACTIVATED })
 
-    const subject = await User.checkAuth(decode(oldToken))
+    await expect(User.checkAuth(decode(oldToken))).rejects.toThrow()
+
+    /* And a freshly issued one does work — the subject is usable again, its old tokens are not. */
+    const reissued = await mutation.generateApplianceSecret(issued.id, context())
 
-    expect(subject).toBeTruthy()
-    expect(subject.id).toEqual(appuser!.id)
-    expect(subject.password).toBeNull()
+    await expect(User.checkAuth(decode(reissued.accessToken))).resolves.toBeTruthy()
   })
 })

package/tests/appliance-schema.test.ts

@@ -0,0 +1,129 @@
+/**
+ * The appliance resolvers make a schema, and the two new fields carry the gate they meant to.
+ *
+ * ── Why a schema test and not another unit test ─────────────────────────────
+ * `credentialRevoked` is a field with no column behind it and `applianceCredentialRevocable` is
+ * a Query on a resolver whose other methods all return objects. Both are the shapes that build
+ * fine in TypeScript and fail when type-graphql reads the decorators — an inferred type it
+ * cannot resolve takes the whole schema down, and a schema that does not build is a server that
+ * comes up without its doors (`reference_resolver_load_failure_leaves_server_half_up`).
+ *
+ * ── What the gate assertion is for ──────────────────────────────────────────
+ * `applianceCredentialRevocable` exists so a screen can ask "would pressing revoke work for
+ * me". That answer is only worth anything if the query is refused in the same cases the
+ * mutation is, so the two declarations have to stay identical. Nothing else would notice them
+ * drifting apart: the query would simply start answering people who cannot act on it, and the
+ * button would appear and then refuse.
+ */
+
+import { buildSchema } from 'type-graphql'
+import { GraphQLSchema } from 'graphql'
+
+import { loadCompiled } from './compiled'
+
+const { ApplianceQuery } = loadCompiled('service/appliance/appliance-query')
+const { ApplianceMutation } = loadCompiled('service/appliance/appliance-mutation')
+const { ApplicationQuery } = loadCompiled('service/application/application-query')
+const { ApplicationMutation } = loadCompiled('service/application/application-mutation')
+const { AppBindingQuery } = loadCompiled('service/app-binding/app-binding-query')
+const { AppBindingMutation } = loadCompiled('service/app-binding/app-binding-mutation')
+const { privilegeDirectiveResolver, privilegeOfField } = loadCompiled('service/privilege/privilege-directive')
+
+let schema: GraphQLSchema
+
+beforeAll(async () => {
+  schema = await buildSchema({
+    resolvers: [
+      ApplianceQuery,
+      ApplianceMutation,
+      ApplicationQuery,
+      ApplicationMutation,
+      AppBindingQuery,
+      AppBindingMutation
+    ],
+    validate: false
+  })
+
+  /* The map of what each field asks for is filled in while the directive walks the schema. */
+  privilegeDirectiveResolver(schema)
+})
+
+describe('the schema builds', () => {
+  it('has the query the screen asks before showing a revoke button', () => {
+    const field = schema.getQueryType()?.getFields()['applianceCredentialRevocable']
+
+    expect(field).toBeDefined()
+
+    /* Non-null: it always has an answer, and "no answer" would read as "no button". */
+    expect(String(field!.type)).toEqual('Boolean!')
+  })
+
+  it('has the field that separates revoked from never issued', () => {
+    const field = schema.getType('Appliance')?.['getFields']()['credentialRevoked']
+
+    expect(field).toBeDefined()
+
+    /*
+     * Nullable, unlike the query above. This field rides on the Appliance type, which is also
+     * what the mutations hand back, and a caller that does not ask for it should get a record
+     * without it rather than one asserting the credential is live. The screen reads absent as
+     * not revoked — `client/utils/credential-panel-state.ts` in auth-ui pins that.
+     */
+    expect(String(field.type)).toEqual('Boolean')
+  })
+
+  it('still has the door those two describe', () => {
+    expect(schema.getMutationType()?.getFields()['revokeApplianceCredential']).toBeDefined()
+  })
+})
+
+describe('the question is gated like the act it describes', () => {
+  it('asks for exactly what revoking asks for', () => {
+    /*
+     * ⚠ The pair that has to stay together. If the query opened up, it would answer yes to a
+     * reader the mutation refuses, and the screen would put a button in front of somebody who
+     * cannot press it.
+     */
+    const asking = privilegeOfField('Query', 'applianceCredentialRevocable')
+    const acting = privilegeOfField('Mutation', 'revokeApplianceCredential')
+
+    expect(asking.known).toBe(true)
+    expect(acting.known).toBe(true)
+    expect(asking['gate']).toEqual(acting['gate'])
+  })
+
+  it('is not an open field', () => {
+    /* `null` is how the map records a root field that declares nothing. */
+    expect(privilegeOfField('Query', 'applianceCredentialRevocable')['gate']).not.toBeNull()
+  })
+})
+
+describe('no door on a machine credential is left open', () => {
+  /*
+   * ⚠ The sweep this file exists for as much as for the two fields above. `deleteAppBinding`
+   * carried no privilege at all, and nothing noticed: an undeclared root field is recorded as
+   * open, so it reads exactly like a field somebody decided to open. The two app binding reads
+   * were the same.
+   *
+   * These three resources are one family — an appliance, an application, and a client bound to
+   * one — and every way in or out of them is a machine credential. So the assertion is on the
+   * whole family rather than on the doors that happen to be remembered.
+   */
+
+  /** Every root field these six resolvers put in the schema. */
+  function rootFields(typeName: string): string[] {
+    const type = typeName === 'Query' ? schema.getQueryType() : schema.getMutationType()
+
+    return Object.keys(type?.getFields() || {})
+  }
+
+  it.each(['Query', 'Mutation'])('%s', typeName => {
+    const open = rootFields(typeName).filter(field => {
+      const declared = privilegeOfField(typeName, field)
+
+      return declared.known && declared['gate'] === null
+    })
+
+    expect(open).toEqual([])
+  })
+})

package/tests/application-delete-db.test.ts

@@ -0,0 +1,190 @@
+/**
+ * Deleting an application has to stop the clients bound to it.
+ *
+ * ── The asymmetry this came from ────────────────────────────────────────────
+ * An appliance and an application both have a shadow `User` standing in for the machine, and
+ * that user is the thing a token names. `deleteAppliance` deletes it along with the appliance.
+ * `deleteApplication` deleted only the application row, and the shadow users stayed behind:
+ *
+ *   ACTIVATED, so `User.checkAuth` passes every token naming them — it looks the user up by the
+ *   id in the token and never asks whether the application still exists
+ *
+ *   holding a refresh token in `password`, which is what `/oauth2/refresh-token` finds a binding
+ *   by, so each refresh mints another year of them
+ *
+ * So the screen said the application was gone and its clients kept working, with no way left on
+ * any screen to reach them — the list they would have appeared in is keyed on an application
+ * that no longer exists.
+ *
+ * ⚠ sqlite (`tests/db.ts`).
+ */
+
+import { closeAuthDatabase, Domain, getRepository, openAuthDatabase, resetAuthDatabase } from './db'
+import { loadCompiled } from './compiled'
+
+const { Application } = loadCompiled('service/application/application')
+const { User, UserStatus } = loadCompiled('service/user/user')
+const { ApplicationMutation } = loadCompiled('service/application/application-mutation')
+
+const mutation = new ApplicationMutation()
+
+let domain: any
+let other: 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 makeApplication(name: string, d: any = domain) {
+  return await mutation.createApplication(
+    {
+      name,
+      email: `${name}@acme.z`,
+      url: `https://${name}.example.com`,
+      redirectUrl: `https://${name}.example.com/callback`,
+      type: 'OTHERS'
+    },
+    context(d)
+  )
+}
+
+/** A binding, as the OAuth2 exchange leaves one: a shadow user holding a refresh token. */
+async function bind(application: any, label: string, d: any = domain) {
+  const appuser = await getRepository(User).save({
+    username: `${label}@acme`,
+    email: `${label}@acme`,
+    name: label,
+    userType: 'application',
+    reference: application.id,
+    status: UserStatus.ACTIVATED,
+    domains: [d]
+  })
+
+  const refreshToken = Application.generateRefreshToken(d, appuser, application, 'admin')
+
+  return await getRepository(User).save({ ...appuser, password: refreshToken })
+}
+
+async function bindingsOf(applicationId: string) {
+  return await getRepository(User).findBy({ reference: applicationId, userType: 'application' })
+}
+
+beforeAll(async () => {
+  await openAuthDatabase()
+})
+
+afterAll(async () => {
+  await closeAuthDatabase()
+})
+
+beforeEach(async () => {
+  await resetAuthDatabase()
+
+  domain = await getRepository(Domain).save({ name: 'acme', subdomain: 'acme' })
+  other = await getRepository(Domain).save({ name: 'beta', subdomain: 'beta' })
+  actor = await getRepository(User).save({
+    username: 'operator@acme.z',
+    email: 'operator@acme.z',
+    name: 'operator',
+    status: UserStatus.ACTIVATED,
+    domains: [domain]
+  })
+})
+
+describe('deleting an application', () => {
+  it('takes its bindings with it', async () => {
+    /*
+     * ⚠ The case. A binding left behind is a live credential with no screen to reach it from —
+     * the list it would appear in is keyed on an application that is gone.
+     */
+    const application = await makeApplication('billing')
+    await bind(application, 'binding-a')
+    await bind(application, 'binding-b')
+
+    await mutation.deleteApplication(application.id, context())
+
+    expect(await bindingsOf(application.id)).toHaveLength(0)
+  })
+
+  it('leaves no token that checkAuth would still accept', async () => {
+    /*
+     * ⚠ Why the row mattering is not enough to say. `checkAuth` looks the subject up by the id
+     * baked into the token and never asks whether the application exists, so a surviving user
+     * authenticates whatever happened to the application row.
+     */
+    const application = await makeApplication('billing')
+    const binding = await bind(application, 'binding-a')
+
+    await mutation.deleteApplication(application.id, context())
+
+    await expect(
+      User.checkAuth({ id: binding.id, userType: 'application', domain: { subdomain: 'acme' } })
+    ).rejects.toThrow()
+  })
+
+  it('deletes the application row itself', async () => {
+    const application = await makeApplication('billing')
+
+    await mutation.deleteApplication(application.id, context())
+
+    expect(await getRepository(Application).findOneBy({ id: application.id })).toBeNull()
+  })
+
+  it('leaves another application and its bindings alone', async () => {
+    const going = await makeApplication('billing')
+    const staying = await makeApplication('shipping')
+
+    await bind(going, 'binding-a')
+    const kept = await bind(staying, 'binding-b')
+
+    await mutation.deleteApplication(going.id, context())
+
+    expect(await bindingsOf(staying.id)).toHaveLength(1)
+    expect(await getRepository(User).findOneBy({ id: kept.id })).toMatchObject({ status: UserStatus.ACTIVATED })
+  })
+
+  it('does not reach into another tenant', async () => {
+    /*
+     * The delete is scoped by domain, so an id from elsewhere matches nothing. The bindings must
+     * not be cleared on the way to finding that out.
+     */
+    const theirs = await makeApplication('billing', other)
+    await bind(theirs, 'binding-theirs', other)
+
+    await mutation.deleteApplication(theirs.id, context(domain))
+
+    expect(await getRepository(Application).findOneBy({ id: theirs.id })).not.toBeNull()
+    expect(await bindingsOf(theirs.id)).toHaveLength(1)
+  })
+
+  it('does not touch an appliance that happens to carry the same reference', async () => {
+    /*
+     * `reference` is a plain column shared by both kinds of shadow user, so the delete has to
+     * name `userType` as well. Two ids never collide in practice; the assertion is about the
+     * filter, not about the odds.
+     */
+    const application = await makeApplication('billing')
+
+    const applianceUser = await getRepository(User).save({
+      username: 'device@acme',
+      email: 'device@acme',
+      name: 'device',
+      userType: 'appliance',
+      reference: application.id,
+      status: UserStatus.ACTIVATED,
+      domains: [domain]
+    })
+
+    await mutation.deleteApplication(application.id, context())
+
+    expect(await getRepository(User).findOneBy({ id: applianceUser.id })).not.toBeNull()
+  })
+})

package/tests/application-token-payload-db.test.ts

@@ -0,0 +1,185 @@
+/**
+ * What an application's tokens carry in their payload.
+ *
+ * ── Why this is worth a file of its own ─────────────────────────────────────
+ * An application has two 32-character hex strings and they are opposite kinds of thing:
+ *
+ *   appKey     the client id. Public. It is what a token says it was issued to, and what the
+ *              OAuth2 refresh exchange looks the application up by.
+ *   appSecret  the client secret. It is what `/oauth2/access-token` compares against to decide
+ *              the caller is that client.
+ *
+ * `Application.sign` takes the first in a positional slot, and a JWT payload is not encrypted —
+ * anyone holding the token reads it. So putting the second one in that slot hands the client
+ * secret to whoever holds the token, and nothing about the call site looks wrong at a glance:
+ * both values are strings on the same object.
+ *
+ * That is exactly what `renewApplicationAccessToken` did. These cases pin the axis the fix
+ * splits — what the payload names — rather than the shape of the call.
+ *
+ * ── What these do not cover ─────────────────────────────────────────────────
+ * The tokens issued before the fix. They carry the secret and they keep carrying it, and the
+ * decision is to leave them (2026-09-20 사용자 결정: 이미 발행된 토큰은 무시한다). So there is
+ * no audit here and no rule for finding them — only that nothing new goes out that way.
+ *
+ * ⚠ sqlite (`tests/db.ts`).
+ */
+
+import { closeAuthDatabase, Domain, getRepository, openAuthDatabase, resetAuthDatabase } from './db'
+import { loadCompiled } from './compiled'
+
+const jwt = require('jsonwebtoken')
+
+const { Application } = loadCompiled('service/application/application')
+const { User, UserStatus } = loadCompiled('service/user/user')
+const { ApplicationMutation } = loadCompiled('service/application/application-mutation')
+
+const mutation = new ApplicationMutation()
+
+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
+}
+
+/** An application plus the shadow user a binding is, which the OAuth2 exchange creates. */
+async function bindApplication(name: string) {
+  const application = await mutation.createApplication(
+    {
+      name,
+      email: `${name}@acme.z`,
+      url: `https://${name}.example.com`,
+      redirectUrl: `https://${name}.example.com/callback`,
+      type: 'OTHERS'
+    },
+    context()
+  )
+
+  const appuser = await getRepository(User).save({
+    username: `${application.appKey}@acme`,
+    email: `${application.appKey}@acme`,
+    name,
+    userType: 'application',
+    reference: application.id,
+    status: UserStatus.ACTIVATED,
+    domains: [domain]
+  })
+
+  return { application, appuser }
+}
+
+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('the two strings are not interchangeable', () => {
+  it('gives an application a key and a secret that differ', async () => {
+    /* If these were ever the same value the rest of this file would pass for the wrong reason. */
+    const { application } = await bindApplication('billing')
+
+    expect(application.appKey).toBeTruthy()
+    expect(application.appSecret).toBeTruthy()
+    expect(application.appKey).not.toEqual(application.appSecret)
+  })
+})
+
+describe('renewing an application access token', () => {
+  it('names the application by its key', async () => {
+    const { application, appuser } = await bindApplication('billing')
+
+    const { accessToken } = await mutation.renewApplicationAccessToken(appuser.id, context(), 'admin')
+
+    expect(jwt.decode(accessToken).application.appKey).toEqual(application.appKey)
+  })
+
+  it('does not put the client secret in the access token', async () => {
+    /*
+     * ⚠ The defect. A JWT payload is base64, not encryption — whoever holds the token reads it.
+     * With the secret and the key, which is public, a holder can call `/oauth2/access-token` as
+     * that client.
+     */
+    const { application, appuser } = await bindApplication('billing')
+
+    const { accessToken } = await mutation.renewApplicationAccessToken(appuser.id, context(), 'admin')
+
+    expect(JSON.stringify(jwt.decode(accessToken))).not.toContain(application.appSecret)
+  })
+
+  it('does not put it in the refresh token either', async () => {
+    /*
+     * ⚠ The longer-lived half. The access token is 30 days; this one is a year, and it is the
+     * one handed to the client to keep.
+     */
+    const { application, appuser } = await bindApplication('billing')
+
+    const { refreshToken } = await mutation.renewApplicationAccessToken(appuser.id, context(), 'admin')
+
+    expect(jwt.decode(refreshToken).application.appKey).toEqual(application.appKey)
+    expect(JSON.stringify(jwt.decode(refreshToken))).not.toContain(application.appSecret)
+  })
+
+  it('does not leave it in the row it stores', async () => {
+    /*
+     * The refresh token is saved on the shadow user's `password`, so a payload carrying the
+     * secret writes the secret into a second place as well.
+     */
+    const { application, appuser } = await bindApplication('billing')
+
+    await mutation.renewApplicationAccessToken(appuser.id, context(), 'admin')
+
+    const stored = await getRepository(User).findOneBy({ id: appuser.id })
+
+    expect(stored.password).toBeTruthy()
+    expect(JSON.stringify(jwt.decode(stored.password))).not.toContain(application.appSecret)
+  })
+
+  it('mints a refresh token the OAuth2 exchange can resolve back to the application', async () => {
+    /*
+     * ⚠ The second face of the same defect, and the one an operator would notice. The refresh
+     * exchange reads `application.appKey` out of the token and does `findOneBy({ appKey })`
+     * (`router/oauth2/oauth2-server.ts`). A payload naming the secret finds no row, so the
+     * exchange answers "application is not exist" and the client cannot refresh at all.
+     */
+    const { application, appuser } = await bindApplication('billing')
+
+    const { refreshToken } = await mutation.renewApplicationAccessToken(appuser.id, context(), 'admin')
+    const named = jwt.decode(refreshToken).application.appKey
+
+    expect(await getRepository(Application).findOneBy({ appKey: named })).toMatchObject({ id: application.id })
+  })
+
+  it('does not name one application with the key of another', async () => {
+    const a = await bindApplication('billing')
+    const b = await bindApplication('shipping')
+
+    const renewed = await mutation.renewApplicationAccessToken(a.appuser.id, context(), 'admin')
+
+    expect(jwt.decode(renewed.accessToken).application.appKey).toEqual(a.application.appKey)
+    expect(jwt.decode(renewed.accessToken).application.appKey).not.toEqual(b.application.appKey)
+  })
+})