GitHub Blog: Notice about upcoming new format for GitHub App installation tokens
We’re now supporting a new, stateless token format for GitHub App installation tokens that improves token issuance performance under increased load and helps us deliver higher reliability at scale.
Newly issued GitHub App installation tokens will use an updated format with the changes below:
The overall length of the tokens will be longer (~520 characters) and will vary based on the data stored within it.
The token format for installation tokens (ghs_ tokens) will be changing to ghs_APPID_JWT.
Note that the prefixes for any of the GitHub token types is not changing and installation tokens will still be prefixed with ghs_.
The JWT is signed using a GitHub-internal issuer and cannot nor should not be validated by a client app. It contains details about the token such as the target installation, the application, and basic validation details. As with all access tokens, client apps must not take a dependency on the contents of this JWT.
On the one-hand we should replace kingfisher.github.5 with this new format once it is fully rolled out since installation tokens are only valid for 1-hour (except GitHub Actions which has an exception for 24 hour tokens iirc).
However, there's an argument for keeping the old format also for all of the GitHub enterprise server (GHES) on-prem installations using older versions... Except those older formats would fail on validation due to the hardcoded github.com domain in the rules...
Any thoughts on the best approach? Maybe it's irrelevant since GitHub is doing a staged rollout so we'll need a second rule anyway.
GitHub Blog: Notice about upcoming new format for GitHub App installation tokens
On the one-hand we should replace
kingfisher.github.5with this new format once it is fully rolled out since installation tokens are only valid for 1-hour (except GitHub Actions which has an exception for 24 hour tokens iirc).However, there's an argument for keeping the old format also for all of the GitHub enterprise server (GHES) on-prem installations using older versions... Except those older formats would fail on validation due to the hardcoded
github.comdomain in the rules...Any thoughts on the best approach? Maybe it's irrelevant since GitHub is doing a staged rollout so we'll need a second rule anyway.