Why ghtkn Is Still Needed Even as GitHub CLI Supports Short-Lived Tokens

GitHub CLI adds short-lived tokens

GitHub CLI (gh) now supports short-lived tokens that refresh automatically. The feature is still in public preview and is opt-in for now. GitHub plans to make it the default later. Some readers may think this makes third-party tools like ghtkn unnecessary. The author disagrees and plans to keep building ghtkn.

What ghtkn does

ghtkn is a command-line tool that gets User Access Tokens from a GitHub App, for use in local development. An access token expires in 8 hours, but a refresh token lasts longer. A refresh token gets a new access token when the old one expires. If the refresh token is stolen, an attacker can keep making new access tokens, so protecting it is the key issue.

Key facts from the article

• Access tokens expire after 8 hours.
• Refresh tokens expire if unused for 6 months.
• Each refresh issues a new refresh token.
• gh stores tokens in the OS keyring by default. If the keyring write fails, gh saves tokens in a plain-text hosts.yml file and shows only a one-line warning.
• gh tokens need at least the repo, read:org, and gist scopes, so they cannot be read-only.

Why the difference matters

The author says ghtkn has clear security advantages. ghtkn encrypts the refresh token and never returns it through the agent API. It limits access to the organizations and repositories where the app is installed. It lets users pick apps with different permissions. It also never stores refresh tokens in plain text. gh tokens, by contrast, can reach every repository the user can access. The author says these advantages still matter after gh adds short-lived tokens.

What to watch

• Whether GitHub CLI's short-lived tokens become the default and how that changes token storage.
• Whether the OS keyring weakness described for macOS is fixed or changed.
• The ghtkn docs command in version v0.4.2 and later, and the ghtkn agent skill.