> You to keep your GitHub tokens/auth in a password manager that requires you to manually authorize unsealing of the token
This is a failure of the GH CLI, IMO. If you log into the GH CLI, it gets access to upload repositories, and doesn’t require frequent re-auth. Unlike AWS CLI, which expires every 18hr or something like that depending on the policy. But in either case (including with AWS CLI), it’s simply too easy to end up with tokens in plaintext in your local env. In fact, it’s practically the default.
These tokens never expire, and there is no way for organization administrators to get them to expire (or revoke them, only the user can do that), and they are also excluded from some audit logs. This applies not just to gh cli, but also several other first party apps.
After discussing our concerns about these tokens with our account team, we concluded the only reasonable way to enforce session lengths we're comfortable with on GitHub cloud is to require an IP allowlist with access through a VPN we control that requires SSO.
This is a failure of the GH CLI, IMO. If you log into the GH CLI, it gets access to upload repositories, and doesn’t require frequent re-auth. Unlike AWS CLI, which expires every 18hr or something like that depending on the policy. But in either case (including with AWS CLI), it’s simply too easy to end up with tokens in plaintext in your local env. In fact, it’s practically the default.