Developers of GitHub Apps can simplify their application by using the client ID for both OAuth flows and the installation token flow.
To date, GitHub Apps have had two different IDs to manage – the application ID and the client ID. The application ID was only used to mint a JWT, subsequently used to fetch an installation token. The client ID is used with the OAuth flow to sign in users and request installations. These two values equally identify the application and the question of which one to use where caused unnecessary developer friction. You can now use the client ID in the place of the application ID when minting JWTs.
The application ID is not being deprecated at this time, nor are their plans to remove it. However, compatibility with future features will rely on use of the client ID, so updating is recommended.
The specific change allowed here is that when minting the JWT that proves your app is in posession of an application’s private key, you can use the client ID for the iss claim. Note that application IDs are ints, while client IDs are strings, if using a typed language.
require 'openssl'
require 'jwt' # https://rubygems.org/gems/jwt
# Private key contents
private_pem = File.read("YOUR_PATH_TO_PEM")
private_key = OpenSSL::PKey::RSA.new(private_pem)
# Generate the JWT
payload = {
# issued at time, 60 seconds in the past to allow for clock drift
iat: Time.now.to_i - 60,
# JWT expiration time (10 minute maximum)
exp: Time.now.to_i + (10 * 60),
--- # GitHub App's App ID
--- iss: "12345"
+++ # GitHub App's Client ID
+++ iss: "Iv23f8doAlphaNumer1c"
}
jwt = JWT.encode(payload, private_key, "RS256")
puts jwt
Note that Octokit still expects the use of the App ID in its setup – the Octokit SDK will be updated in the future to support use of the client ID.
You can find the client ID for your application in its settings page:
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.
GitHub’s audit log streaming health check is now generally available! The purpose of the audit log health check is to ensure audit log streams do not fail silently. Every 24 hours, a health check runs for each stream. If a stream is set up incorrectly, an email will be sent to the enterprise owners as notification that their audit log stream is not properly configured.
Streamed audit logs are stored for up to seven days on GitHub.com. To avoid audit log events being dropped from the stream, a misconfigured stream must be fixed within six days of email notification. To fix your streaming configuration, follow the steps outlined in “Setting up audit log streaming.”
npm feedback is now available on GitHub Community. Previously feedback for npm took place on the npm feedback channel, which is going to be sunset as we migrate unresolved discussions.
External users should utilize the new npm category on GitHub Community to make suggestions to any part of npm, the cli, the registry, and the website. Users can vote and rank topics to voice their opinions and give support to existing items.
Please join us on GitHub Community to share your feedback on npm!