Are GitHub App installation IDs considered sensitive—should we store them securely in a database?

[Aakash4792]

Select Topic Area

Question

Body

We’re integrating a GitHub App and will persist each org’s installation ID in a database.
Is an installation ID considered a secret that should be encrypted/treated like credentials, or is it safe to store as a normal identifier (similar to an organization name or org ID)?

Context:

We understand installation access tokens and the app private key must be protected.

The question is specifically about the installation ID itself (the numeric identifier used in GitHub’s installation token flow).

Looking for:

Best-practice guidance (security/compliance perspective)

Any official GitHub references or community consensus on handling installation IDs

[vladlen-codes]

The installation ID is not a secret and does not need to be encrypted. It can be stored as a plain identifier, similar to an org ID.

Q: Is it safe?
A: Yes, The installation ID alone cannot be used to authenticate or perform any actions on GitHub. To generate an installation access token which is what actually grants API access, you need both:

• The installation ID, AND
• A valid JWT signed with your App's private key

Without the private key, the installation ID is useless to an attacker. It's effectively just a lookup key.

To understand better think of it like a username vs a password. The installation ID is the username knowing it doesn't grant access. The private key is the password that's what must be protected.

If this was helpful please mark it as answered. Thank you!

[alpha37283]

The installation ID itself is generally treated as a non-secret identifier. It’s mainly a reference that tells the API which installation you are requesting a token for. By itself it cannot be used to authenticate or perform actions.

The important security boundary in the GitHub App flow is the private key used to sign the JWT. When requesting an installation access token, GitHub verifies that the request is signed with the app’s private key. Without that key, the installation ID alone cannot produce a valid token.

Because of that, most implementations store the installation ID as a normal database field (similar to org ID or repo ID). The things that should be treated as sensitive are:

the app private key

generated installation access tokens

any stored refresh or authentication secrets

A typical flow looks like:

1. App signs JWT using private key
2. Request installation token using installation_id
3. GitHub verifies JWT
4. GitHub returns installation access token

If someone only knows the installation_id, they still cannot complete step 1. So from a security perspective it functions more like a lookup identifier than a credential.

For compliance-sensitive systems, some teams still restrict exposure of IDs in logs or public APIs, but encryption of the installation ID itself is usually unnecessary unless your internal policy requires it.

[ash-iiiiish]

The GitHub Changelog explicitly addresses this question. In an announcement regarding GitHub Apps now being able to use client IDs for installation tokens, GitHub states: "Client IDs and application IDs are not secrets, and are expected to be visible to the end user – you do not need to change how you handle your IDs when making this update.

Why Installation IDs Are Not Secrets

The installation ID functions as a lookup key, not an authenticator. To generate an installation access token, an attacker would need:

A valid installation ID (which you store)

Your app's private key (which you protect separately)

Your app ID or client ID (publicly visible)

Without the private key, the installation ID is useless for authentication. This aligns with GitHub's principle of using persistent, unique IDs for referencing resources rather than mutable identifiers like handles or emails .

Implementation Recommendation

Store installation IDs as plain integers or strings in your database. Use them as foreign keys to link organizations with their app installations. The same applies to organization IDs, user IDs, and repository IDs—all should be stored as normal identifiers.

Security Note

One caveat: if your application exposes installation IDs directly in URLs or client-side code (such as in setup URL redirects), be aware that these values can be enumerated. GitHub explicitly warns not to rely on installation_id parameters for authorization decisions, as malicious actors could access your setup URL with forged installation IDs . Always validate installations by generating user access tokens and checking ownership rather than trusting the ID alone.

[weebaayush]

No — a GitHub App installation ID is not considered a secret and generally does not need to be encrypted or treated like credentials.

An installation ID is simply a numeric identifier that represents the installation of a GitHub App on a user or organization. By itself, it does not grant any access to GitHub resources. To generate an installation access token, the request must be authenticated using a JWT signed with the GitHub App’s private key. Without the private key, the installation ID alone cannot be used to obtain tokens or access data.

Because of this design, installation IDs are typically treated the same way as other identifiers such as organization IDs, repository IDs, or app IDs. It is common practice to store them as normal database fields without encryption.

From a security perspective, the components that must be protected are:

The GitHub App private key

Installation access tokens

Any OAuth client secrets

These should be stored securely (for example, in a secrets manager or encrypted storage).

GitHub’s documentation focuses on protecting credentials such as private keys and tokens, while identifiers like installation IDs are expected to be used in API calls and stored as part of application state.

Summary:
Installation IDs are identifiers, not credentials. They can safely be stored as normal database values, while sensitive credentials like private keys and tokens must be protected.