I was passing an int to Auth as per its typing annotations, which I didn't initially realize was cascading into a problem with the JWT RFC violation.

This was when I was writing some tests that supply a legit RSA keypair and exercise create_jwt().

I then attempt to decode the payload with signature verification. I attempted jwt.decode(..., issuer=123) / jwt.decode(..., issuer='123') and hit errors in both cases. So I troubleshooted the problem and discovered that PyGitHub uses App ID as an integer value when constructing JWT payload. But the JWT spec is pretty clear about the expectation that it must be a string:

4.1.1. "iss" (Issuer) Claim

The "iss" (issuer) claim identifies the principal that issued the
JWT. The processing of this claim is generally application specific.
The "iss" value is a case-sensitive string containing a StringOrURI
value. Use of this claim is OPTIONAL.

(emphasis mine)

So the bug in PyGitHub is that it doesn't turn the number into a string, and the bug in PyJWT is that it allows it in the first place. I also filed the issue over there too: jpadilla/pyjwt#1039.

GitHub's own docs correctly show it as being a string as well: https://docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app/generating-a-json-web-token-jwt-for-a-github-app#example-using-python-to-generate-a-jwt.

Implementing this will also allow supporting Client ID issuer values: #3213.