docs: Provide easy alternative to create App JWT token

[rasmus]

This adds a simple code snippet for creating the JWT token required to authenticate GitHub Apps. All dependencies live in the System namespace.

• System.IdentityModel.Tokens.Jwt
• System.Security.Claims
• System.Security.Cryptography

---

Before the change?

Developers would think that the only alternative was to import another dependency.

After the change?

Developers are able to create JWT tokens for their GitHub Apps using dependencies they likely already have imported.

Pull request checklist

• Tests for the changes have been added (for bug fixes / features)
• Docs have been reviewed and added / updated if needed (for bug fixes / features)

Does this introduce a breaking change?

• Yes
• No

---

[kfcampbell]

Thanks for the contribution, this is great! I would rather encourage people to use system libraries. I had a couple quick questions and a suggestion before shipping.

[kfcampbell]

Is this the key itself or the path to the key? I think this could be made more clear.

[kfcampbell]

What's the advantage of the using statement here?

[rasmus]

Since the RSA object implements the IDisposable interface, its usually required to invoke the .Dispose() when the object leaves scope and is no longer needed. There could be some resources not managed by the runtime that needs cleaning up. I haven't decompiled the code to see what's actually there. The syntax for declaring using without braces was made available in .NET 8.

[rasmus]

@kfcampbell do. I added a code comment regarding the required using statements as well and commented on the using statement

[colbylwilliams]

@rasmus first, thank you for this. This token is one of the most confusing parts of getting started with GitHub Apps.

I noticed an announcement on the GitHub blog directing GitHub Apps to starting using the clientId instead of the appId in the iss when minting these tokens.

From the announcement:

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.

It might be worth updating the sample to use the clientId.

cc: @kfcampbell @nickfloyd

[nickfloyd]

It might be worth updating the sample to use the clientId.

Thanks for following up on this @colbylwilliams, you're correct about the shift. We've made this move in the newly generated SDKs as well.