Does a GitHub App "Client Secret" ever expire?

[Aakash4792]

Select Topic Area

Question

Body

I would like to know if the GitHub App's client secret (that is used for generating user access tokens) ever expire? How are they usually rotated for secure key management?

[Kenzy173]

GitHub App client secrets do not expire automatically. Once generated, a client secret remains valid indefinitely until you manually regenerate it in the GitHub App settings.

How rotation works in practice

Because there’s no built-in expiration or overlapping secret support, rotation is a manual process and requires coordination:

Generate a new client secret

Go to GitHub → Settings → Developer settings → GitHub Apps → Your App

Under Client secrets, click Generate a new client secret

Copy it immediately (GitHub only shows it once)

Update your application configuration

Replace the old secret in your:

Environment variables

Secrets manager (AWS Secrets Manager, Vault, GCP Secret Manager, etc.)

CI/CD system

Redeploy your application

Old secret becomes invalid immediately

GitHub invalidates the previous client secret as soon as a new one is generated.

There is no dual-secret grace period.

This means rotation must be carefully coordinated to avoid downtime.

[Aakash4792]

But a client secret is invalidated only if its "Deleted" right? Not as soon as a new one is generated? Is there a limit on number of client secrets that can be generated?

[Kenzy173]

For GitHub Apps, generating a new client secret does not invalidate the existing ones. A client secret stays valid until you explicitly click Delete next to it. So in your screenshot, both secrets are active and usable right now.

That’s actually intentional so you can rotate safely:

Generate a new secret

Deploy it to your app

Verify everything works

Delete the old one

No downtime required.

As for limits: GitHub doesn’t clearly document a hard maximum number of client secrets, but you can definitely have multiple active at the same time. In practice, you wouldn’t keep many — usually just 1–2 during rotation. It’s not meant to be an unlimited list, but you’re unlikely to hit a ceiling under normal use.

One important security note: if a secret is ever exposed, just generating a new one isn’t enough — you must delete the compromised one, since old secrets remain valid until removed.

[SuryaThejas-07]

No — a GitHub App Client Secret does not expire automatically.

Details:
The Client Secret is valid for an indefinite period of time.
The client secret is used to authenticate your GitHub App when you exchange the OAuth code for an access token.
GitHub will not automatically rotate or invalidate it.

When it stops working:
A client secret will become invalid only under the following circumstances:
You have manually regenerated it in the GitHub App settings.
The app has been deleted.
The secret has been revoked as a result of a security action.

[PSMatheus01]

To answer your question directly: no, GitHub App client secrets do not expire. They stay valid until you explicitly delete them. Your screenshot actually confirms this — you have two active secrets coexisting, one from 2 weeks ago and one from 1 minute ago, both valid.

And yes, you can have multiple client secrets active at the same time. Generating a new one does not invalidate the old ones. Only clicking "Delete" does.

This is actually by design, because it enables zero-downtime rotation:

1. Generate a new secret
2. Deploy it to your app / secrets manager
3. Verify everything works
4. Delete the old secret

One thing worth clarifying since it trips people up: don't confuse the client secret with other GitHub App credentials — they each have different lifetimes:

Credential	Expires?	Used for
Client secret	Never (until deleted)	OAuth flow to generate user access tokens
Private key (PEM)	Never (until deleted)	Signing JWTs to authenticate as the app itself
User access token	8 hours by default	API calls on behalf of a user
Installation access token	1 hour	API calls as the app installation

For rotation best practices in production: store the client secret in a proper secrets manager (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager, Azure Key Vault — all have free tiers or are included in cloud accounts) rather than env files or hardcoded config. That way rotation is just updating the value in one place and redeploying, instead of hunting through config files.

GitHub doesn't publicly document a hard limit on how many client secrets you can have active simultaneously, but in practice you'd only ever need 2 — the current one and the one you're rotating to. No reason to keep more than that around.