Repository navigation
Add first party support for Github App #3005
Description
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:
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.
Activity
WillAbides commentedon Nov 29, 2023
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 commentedon Nov 30, 2023
Both.
gmlewis commentedon Nov 30, 2023
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
ghinstallationrepo 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 commentedon Nov 30, 2023
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 commentedon Jun 1, 2024
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.TokenSourceand could be used withoauth2.ReuseTokenSourceto handle token refreshing.alvaroaleman commentedon Sep 1, 2024
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.