Add first party support for Github App

[ashi009]

Many of the apis requires to be invoked as Github App, eg. https://docs.github.com/en/rest/checks/runs?apiVersion=2022-11-28. And currently we need to use third-party packages like ghinstallation to do so.

However, this is not the full story. When creating a Github App, it involves many different kinds of creds:

• as Github App itself
• as Github App installation
• as Github App user

And we need to use different cred to call different APIs. For now, the only way to do so is to create many different github.Clients, each holding a different credential.

And we need to do this with extra care, as all these token are short-lived, and need to be cached/refreshed periodically. Which means, blindly creating those clients will cause lots of rate limiting issues.

For instance, to use github.ChecksService, we need:

• Auth as Github App itself by creating a JWT with app's private key, to call github.AppServiceCreateInstallationToken
• Once we have the token, we can auth as app installation, then calling github.ChecksService

Which requires 2 github.Clients in total.

[WillAbides]

I don't quite understand what is being proposed here. Is it the idea of handling auth in go-github itself to save from having to bring in third party dependencies or is it something bigger that looks at the endpoint being called and chooses the right kind of authentication to use?

[ashi009]

Both.

• bring in the code for generating the app JWT and auto refresh installation token, which is like less than 100 lines of code if use "github.com/golang-jwt/jwt/v5" and "golang.org/x/oauth2"
• make some change to the API to allow switching between creds more easily

[gmlewis]

Hmmm... one of the things we try hard to do in this repo is keep the dependencies to an absolute minimum.
I'm not sure that we really want to pull in JWT manipulation code as a dependency here.
I'm fine with adding examples that pull in those dependencies, but not as helpers in the main repo if we can avoid it.

In fact, this exact conversation is how the ghinstallation repo was originally started as an external helper repo.

If you want that kind of functionality, we prefer that it is implemented in an external repo and we are happy to point to it from this repo as an example of usage.

[WillAbides]

I agree with what @gmlewis is saying, but it would still be interesting to explore this idea as a whole. Then we can see if there is a way to make it work that is feasible to maintain.

@ashi009 I'm especially curious to see your ideas of making it easier to switch between creds. Do you have suggestions of what the API changes would look like?

As somebody who occasionally uses app and installation authentication, one thing I struggle with is keeping track of which endpoints require which creds. I have a rough idea that this could be improved, but I haven't proposed anything. I only occasionally dabble in apps so I feel like I don't have a full understanding of the problem.

[jferrl]

Many of the apis requires to be invoked as Github App, eg. https://docs.github.com/en/rest/checks/runs?apiVersion=2022-11-28. And currently we need to use third-party packages like ghinstallation to do so.

However, this is not the full story. When creating a Github App, it involves many different kinds of creds:

• as Github App itself
• as Github App installation
• as Github App user

And we need to use different cred to call different APIs. For now, the only way to do so is to create many different github.Clients, each holding a different credential.

And we need to do this with extra care, as all these token are short-lived, and need to be cached/refreshed periodically. Which means, blindly creating those clients will cause lots of rate limiting issues.

For instance, to use github.ChecksService, we need:

• Auth as Github App itself by creating a JWT with app's private key, to call github.AppServiceCreateInstallationToken
• Once we have the token, we can auth as app installation, then calling github.ChecksService

Which requires 2 github.Clients in total.

Hello @ashi009 I faced the same situation and I created a similar issue #3178.

Thread discussion with @gmlewis led to creating a new package to handle this functionality. https://github.com/jferrl/go-githubauth. Just take a look, its compatible with golang.org/x/oauth2 oauth2.TokenSource and could be used with oauth2.ReuseTokenSource to handle token refreshing.

[alvaroaleman]

Just as a reference, a couple of years ago I wrote this http transport for Prow that can be used to authenticate against many orgs and does everything transparently by inferring the org form the request: https://github.com/kubernetes-sigs/prow/blob/195f38540f39dd3ec95ca2d7086487ec19922e61/pkg/github/app_auth_roundtripper.go

That kind of approach might be neat here, too and maybe some of that code can be re-used.