Token cache invalidation

[snacsnoc]

Environment:

• CLI Version: 0.22.5 installed via homebrew
• OS: macOS
• Auth method: OAuth desktop app
• Keyring backend: keyring

Description:

After re-authenticating with additional scopes, gws auth status shows the new scopes in credentials.enc, but API calls can still use the old cached access token from:

~/.config/gws/token_cache.json

This caused a persistent 403 until I deleted the token cache manually.

Steps to reproduce:

1. Authenticate with a basic scope, for example Drive:

gws auth login --scopes \
'https://www.googleapis.com/auth/drive.readonly,openid,https://www.googleapis.com/auth/userinfo.email,https://www.googleapis.com/auth/userinfo.profile'

2. Run any command that populates the token cache:

gws drive files list --params '{"pageSize":1}'

3. Re-authenticate with an additional scope:

gws auth login --scopes \
'https://www.googleapis.com/auth/drive.readonly,https://www.googleapis.com/auth/admin.reports.audit.readonly,openid,https://www.googleapis.com/auth/userinfo.email,https://www.googleapis.com/auth/userinfo.profile'

4. Confirm gws auth status shows the new scope.

5. Immediately run a command that requires the new scope:

gws admin-reports activities list \
  --params '{"userKey":"all","applicationName":"login","maxResults":1}'

Observed:

The command fails:

{
  "error": {
    "code": 403,
    "message": "Request had insufficient authentication scopes.",
    "reason": "insufficientPermissions"
  }
}

Deleting the token cache fixes it:

rm ~/.config/gws/token_cache.json

After deleting the cache, the same command succeeds

Expected:
After a successful gws auth login, any cached access token using the previous scope set should be invalidated. The next API call should mint a new access token using the newly saved credentials/scopes

Thoughts:
After handle_login_inner successfully saves new credentials, invalidate/delete token_cache.json

[zippeurfou]

+1, hit this on v0.22.5 with a different trigger: major version upgrade.

Workflow that broke:

1. Originally authenticated under v0.7 (gws auth login -s drive,gmail,calendar,sheets) — worked fine for months.
2. Upgraded gws to v0.22.5.
3. Re-authenticated with gws auth login -s drive,gmail,calendar,sheets,docs,chat,tasks. Login reported success with 32 scopes (v0.22.5 expanded per-service scope sets — gmail alone now requests 11 sub-scopes, chat requests 9).
4. gws auth status correctly showed 40 cumulative scopes including https://www.googleapis.com/auth/drive and .../spreadsheets.
5. Every Drive/Sheets call returned 403 insufficientPermissions despite the scopes being present in credentials.enc.
6. rm ~/.config/gws/token_cache.json immediately fixed it. Next API call minted a fresh access token from the refresh token and worked.

Confirms auth login should invalidate token_cache.json regardless of whether the trigger is:

• Adding scopes (your case)
• Upgrading gws across versions where the per-service scope set changed (my case)
• Switching accounts (Token cache not invalidated after gws auth login to a different account #780)

The symptom is particularly confusing because gws auth status reports the new scopes correctly — there's no signal to the user that the on-the-wire token still carries the old/narrower scope set. Suggest the fix in this issue (invalidate cache after handle_login_inner succeeds) plus, separately, surfacing the cached token's actual scopes in gws auth status output (e.g., cached_token_scopes distinct from scopes) would make this a lot easier to diagnose if it happens again before the fix lands.