auth.json v2 #1419

Part of #1383 (Stage-1). Closes #567, except its listing part — see below.

Shape

{
  "version": 2,
  "activeProfile": "<userId>",
  "profiles": {
    "<userId>": {
      "username": "moria",
      "name": null,                     // reserved for Stage-3 `--profile <name>`
      "organizationOwnerUserId": "…",   // set => this profile is an organization
      "authMethod": "token",            // reserved, unused until Stage-4
      "expiresAt": null,                // reserved
      "hasRefreshToken": false          // reserved
    }
  },
  "secretsBackend": "keyring"
}

Keyed by userId, not by a display name. The key names the keyring entry in the next subtask, so a rename must never orphan a secret.

The reserved fields stay unused. authMethod, expiresAt and hasRefreshToken are for the device flow, which issues expiring access tokens when the OAuth app opts into refresh tokens. name is for Stage-3, where a profile gets a human label. Leaving any of them out forces a second migration later.

No proxy object in the profile. The password is a secret and belongs to #1420; nothing reads proxy.groups. On the keyring backend today's code already strips the password and deletes the empty object (utils.ts:203-208).

Fields

Today getLoggedClient does { ...existingFile, ...userInfo }, so the file holds email, plan, effectivePlatformFeatures, isPaying, createdAt and proxy groups. None of them are read anywhere — email is even declared in the AuthJSON type and never used.

Across the 20 getLocalUserInfo() call sites the CLI consumes username, id, token and proxy.password, plus organizationOwnerUserId for labeling organization profiles later. Drop the rest, and drop email from AuthJSON.

Migration

Three states exist in the wild:

ensureMigrated() already turns A into B or C. The v2 shape migration runs after it, as a separate step — do not merge the two functions.

• back up the old file as auth.json.v1.bak, and never overwrite an existing backup
• write via temp file + rename; two CLI processes can run at once
• idempotent, single-flight, never throws — a migration failure must not block a command
• no reverse migration, but an older CLI is not broken by one either. Verified against apify-cli@1.10.0: it finds the token — top-level on the file backend, via the surviving secretsBackend marker on keyring — and its per-command auth.json refresh re-adds the flat id/username, so it self-heals and the file ends up carrying both shapes. No changelog note needed for downgrade. The .bak is still written, and still holds a plaintext token on the file backend.

Edge cases

Also in scope

• getLocalUserInfo() keeps its current return shape, reading the active profile. That keeps the 20 call sites untouched.
• useRentalSunsetNotice.ts:101 reads auth.json directly and bypasses getLocalUserInfo. It will silently stop finding the username otherwise.
• logout calls rimraf on the whole file (logout.ts:29). Route it through the store.
• Add a test helper for reading a profile. Five test files parse auth.json by hand today: run.test.ts (×3), log_in_out.test.ts, info.test.ts, actors/search.test.ts, rental-sunset-notice.test.ts.

Not in scope

No additive login, no --profile, no switch, no list. #567 also asks to print all logged-in accounts — that is auth list, Stage-3 (#1384).

Verification

• A → v2, B → v2, C → v2
• no file → login creates v2
• all of the above with APIFY_DISABLE_KEYRING=1
• migration is a no-op on a file that is already v2
• apify run still gets the right token and proxy password (run.test.ts:128, :169, :209)
• logout removes the profile
• bundle build still loads the native keyring module

🤖 Generated with Claude Code