Support optional Touch ID or user-presence protection for refreshable credentials on macOS #14969

Describe the feature or problem you’d like to solve

The new refreshable OAuth credentials reduce the lifetime of a leaked access token, but gh still needs to retain a refresh token that can obtain new credentials.

On macOS, gh uses Keychain through zalando/go-keyring. The CLI’s [macOS Keyring Security notes](https://github.com/cli/cli/blob/trunk/docs/macos-keyring.md) explain that this invokes /usr/bin/security and that direct calls to security can also access stored gh tokens, subject to Keychain access controls. This makes the refresh credential an interesting target for malicious code running in a developer’s user session.

Could gh offer an optional user-presence requirement, such as Touch ID, to protect refreshable credentials?

Proposed solution

Provide an opt-in macOS credential-storage mode that requires user presence before accessing the refresh token or performing a token refresh.

My preferred experience would be:

1. Use gh normally while the access token remains valid.
2. When the access token needs refreshing, prompt for Touch ID or an appropriate user-presence mechanism.
3. After approval, refresh and continue normally.
4. In non-interactive environments, fail with a clear message rather than hanging indefinitely.

An optional, bounded authentication reuse period could make this practical for frequent commands. The current behavior could remain available for unattended workflows.

This would give users a way to make access to the refresh credential require local user participation, while preserving normal CLI use between refreshes.

Additional context

The current implementation stores access and refresh information together, so prompting only for refresh may require a different storage design. I also understand that changing the macOS Keychain integration has distribution and code-signing tradeoffs, including for Homebrew builds.

I’d appreciate maintainers’ thoughts on:

• Whether macOS Keychain APIs can provide this behavior for gh’s distribution model.
• Whether access and refresh credentials could be protected separately.
• How to support CLI extensions, headless sessions, and a configurable authentication reuse period.
• Whether another credential broker or platform-native mechanism would be a better fit.

Touch ID would be a local access-control improvement, not a guarantee that an extracted bearer token is device-bound. A process that obtains an access token after approval could still copy it.

• [GitHub CLI macOS Keyring Security](https://github.com/cli/cli/blob/trunk/docs/macos-keyring.md)
• [Refreshable credential storage and refresh implementation](Refreshable tokens (2/7): refresher domain, OAuth refresher, storage, and wiring #14451)
• [Apple: accessing Keychain items with Face ID or Touch ID](https://developer.apple.com/documentation/localauthentication/accessing-keychain-items-with-face-id-or-touch-id)