It depends on the credential. A GitHub App installation token lasts about an hour. A GitHub OAuth app token is long-lived by default. A Google refresh token can last until revoked or unused for six months. A static API key lasts until someone expires it. Choose shorter where you can.
Comparison from vendor documentation
| Credential | Documented lifetime | Source of the rule |
|---|---|---|
| GitHub App installation token | Expires after a predefined time, currently 1 hour | GitHub docs |
| GitHub OAuth app token | Long-lived by default, optional expiry after eight hours with a refresh token | GitHub docs |
| Google OAuth refresh token | Until revoked, or invalid after six months unused, with other conditions | Google docs |
| Google refresh token, external app in Testing | Expires after 7 days (basic profile scopes excepted) | Google docs |
| Stripe API key | Until expired or rotated; rotation offers an overlap of up to 7 days | Stripe docs |
| Slack incoming webhook URL | Until the app or URL is removed | Slack docs describe it as containing a secret |
The last row's lifetime is inferred from the documentation, which does not give an expiry. Treat it as no automatic expiry.
Why lifetime matters
A stolen credential is useful for as long as it works. An hour limits an attacker's window. A token with no expiry gives them months. Standards guidance points the same way. RFC 9700, the OAuth security best current practice, says access token privileges should be restricted to the minimum required, that tokens should be audience restricted, and that refresh tokens for public clients must be sender constrained or use rotation.
How to shorten the long ones
- Prefer app or installation credentials that expire over personal tokens, where the platform offers both.
- If you must use long-lived credentials, scope them to the minimum and give each integration its own.
- Set a calendar rotation and an owner.
- Use access policies or network limits that the provider offers, so a stolen key fails from other places.
- Alert on use from unfamiliar addresses.
- Remove credentials that logs show are unused.
Short does not mean safe
A one hour token can still do a lot in an hour. Limit what it can do as well as how long it lives. Short lifetimes also shift work to your code: it must refresh cleanly, and a failure to refresh will break the integration. Build alerts for authorization errors.
Quick check
Is a longer token lifetime ever acceptable?
Yes, for low-risk, read-only jobs with a named owner and a rotation date. Document the decision.
What does sender-constrained mean?
The token is bound to the client that received it, so a thief cannot simply replay it. Common methods are mutual TLS and DPoP.
Safeguard's policies and compliance evidence automation can record credential rotation as a repeating control. Try the free scan at gold.safeguard.sh/scan.
Sources
- Differences between GitHub Apps and OAuth apps, GitHub Docs
- Using OAuth 2.0 to access Google APIs
- API keys, Stripe Documentation
- Sending messages using incoming webhooks, Slack
- RFC 9700, Best Current Practice for OAuth 2.0 Security, IETF
Last reviewed: 19 October 2026.
