Automatic Token Refresh vs Manual Re‑Authentication: Balancing User Convenience and Security

Direct Answer

Yes, GitKraken should introduce a user‑facing toggle to disable silent token refresh. A 30‑day forced re‑authentication interval (with 7‑day, 90‑day, and "on new device" options) balances workflow continuity with credential re‑validation. Notify users via an in‑app banner 7 days before expiry, a toast 24 hours before, and a non‑blocking modal at the deadline with "Re‑authenticate now" and "Remind me in 1 hour" actions.

Current Behavior (Confirmed from OAuth 2.0 Spec & Electron Patterns)

• GitKraken stores long‑lived refresh tokens in the OS keychain (macOS Keychain, Windows Credential Manager, libsecret).
• Access tokens (typically 1‑hour lifetime) are silently refreshed using the stored refresh token.
• No user‑visible setting exists to disable automatic refresh or enforce periodic re‑auth.
• Fallback to manual re‑auth occurs only when the refresh token is revoked, expires (provider‑dependent), or is invalidated by a security event.

Security Trade‑off

Silent refresh eliminates friction but extends credential validity indefinitely without user re‑validation. If a refresh token is compromised (malware, device theft, supply‑chain attack), the attacker maintains access until the provider revokes the token — which may be never for GitHub and Bitbucket (no refresh‑token expiry by default).

Recommended Toggle Design

Notification Strategy

1. 7 days before forced re‑auth: Persistent in‑app banner (dismissible, reappears on restart).
2. 24 hours before: Toast notification with direct link to re‑auth flow.
3. At expiry: Non‑blocking modal with "Re‑authenticate now" and "Remind me in 1 hour" (max 3 reminders, then forced).

Critical Missing Diagnostic

What is the current refresh‑token TTL per provider? This changes the recommended default interval:

• GitHub: 8‑hour access token, no refresh‑token expiry by default
• GitLab: 2‑hour access token, ~2‑week refresh token
• Bitbucket: 1‑hour access token, no refresh‑token expiry by default
• Azure DevOps: 1‑hour access token, 90‑day refresh token

If GitKraken already respects provider‑side refresh‑token expiry, a 30‑day client‑side interval may be redundant for GitLab/Azure but essential for GitHub/Bitbucket. Verify by revoking a refresh token in each provider’s settings and observing GitKraken’s behavior.

Verification Steps (Safe, Scoped)

1. Open GitKraken Preferences → Authentication → connected accounts; check for any "Re‑authenticate" or "Security" settings in v9.x+.
2. Revoke a refresh token in GitHub Settings → Applications → Authorized OAuth Apps; watch whether GitKraken silently retries or prompts.
3. Inspect Electron dev tools (Cmd+Opt+I) → Application → Local Storage/IndexedDB for token metadata (expiry, device_id) if not in OS keychain.
4. Review GitKraken release notes (last 12 months) for "token refresh", "re‑authentication", or "security" keywords.

Cautions & Uncertainties

• GitKraken’s exact token storage/rotation is not publicly documented; assumptions based on OAuth 2.0 spec and Electron keychain patterns.
• Provider policies differ significantly — a single interval may not suit all.
• Device fingerprinting raises privacy considerations; must be transparent and opt‑in.
• Forced re‑auth during active workflows (merge, rebase, push) could cause data loss if not handled at transaction‑aware interruption points.
• Enterprise SSO/SAML setups may have separate session policies that conflict with client‑side intervals.