Skip to content

Proposal: Add GitHub App Token and Installation Token Source Functionality #3178

Closed

Description

@jferrl

Description

Summary

I propose the addition of new functionality to go-github that will enable users to create and manage GitHub App tokens and installation tokens. This feature will enhance the library's capabilities, making it easier for developers to authenticate and interact with GitHub Apps.

Motivation

GitHub Apps are a powerful way to integrate with GitHub, allowing developers to automate workflows and enhance their repositories' functionality. However, generating and managing tokens for GitHub Apps its done outside go-github pkg, implemented by every project that need it. This proposal aims to simplify this process by introducing a new set of functionalities for creating and handling GitHub App tokens and installation tokens.

Design

The main idea is implementing different token sources to authenticate requests TokenSource

type TokenSource interface {
	// Token returns a token or an error.
	// Token must be safe for concurrent use by multiple goroutines.
	// The returned Token must not be modified.
	Token() (Token, error)
}

Proposed code scaffolding

// applicationTokenSource represents a GitHub App token.
// https://docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app/generating-a-json-web-token-jwt-for-a-github-app
type applicationTokenSource struct {}

// ApplicationTokenOpt is a functional option for ApplicationTokenSource.
type ApplicationTokenOpt func(*applicationTokenSource)

// NewApplicationTokenSource creates a new GitHub App token source.
// An application token is used to authenticate as a GitHub App.
func NewApplicationTokenSource(id string, privateKey []byte, opts ...ApplicationTokenOpt) (oauth2.TokenSource, error) {
	return &applicationTokenSource{}, nil
}

// Token creates a new GitHub App token.
// The token is used to authenticate as a GitHub App.
// Each token is valid for 10 minutes.
func (t *applicationTokenSource) Token() (*oauth2.Token, error) {
	return &oauth2.Token{}, nil
}

// InstallationTokenSourceOpt is a functional option for InstallationTokenSource.
type InstallationTokenSourceOpt func(*installationTokenSource)

// InstallationTokenSource represents a GitHub App installation token source.
type installationTokenSource struct {
}

// NewInstallationTokenSource creates a new GitHub App installation token source.
// It could use an application token sources to authenticate requests to retrieve
// the installation token using github API.
func NewInstallationTokenSource(id int64, src oauth2.TokenSource, opts ...InstallationTokenSourceOpt) oauth2.TokenSource {
	return &installationTokenSource{}
}

// Token creates a new GitHub App installation token.
// The token is used to authenticate as a GitHub App installation.
func (t *installationTokenSource) Token() (*oauth2.Token, error) {
	return &oauth2.Token{}, nil
}

Usage

import (
	"context"

	"github.com/google/go-github/v62/github"
	"golang.org/x/oauth2"
)

func main () {
  ctx := context.Background()
  
  appts, _ := github.NewApplicationTokenSource("app_id",  []byte("private_key"))
  its := github.NewInstallationTokenSource("installation_id", appts)
  githubClient := github.NewClient(oauth2.NewClient(ctx, its))
}

Activity

  1. changed the title [-]Proposal: Proposal to Add GitHub App Token and Installation Token Source Functionality[/-] [+]Proposal: Add GitHub App Token and Installation Token Source Functionality[/+] on Jun 1, 2024
  2. gmlewis commented on Jun 1, 2024

    @gmlewis
    Collaborator

    I have 3 concerns.

    1. At one point we went to some effort to remove all references to oauth2 from this repo
    2. I'm wondering why this can't simply exist in an external helper repo like we have done with several other helpers mentioned in our README.md
    3. I'm my experience, a fake private key should never be used in any repo because it causes false vulnerability reports with scanning services that are an extreme pain to work around
  3. jferrl commented on Jun 1, 2024

    @jferrl
    ContributorAuthor

    I have 3 concerns.

    1. At one point we went to some effort to remove all references to oauth2 from this repo
    2. I'm wondering why this can't simply exist in an external helper repo like we have done with several other helpers mentioned in our README.md
    3. I'm my experience, a fake private key should never be used in any repo because it causes false vulnerability reports with scanning services that are an extreme pain to work around

    First of all, thank you for the quick feedback. 😃

    I agree with your concerns and I appreciate it. I'll handle it in an external helper repository to maintain such functionality and then create a PR to update go-github repo README.

    WDYT?

  4. gmlewis commented on Jun 1, 2024

    @gmlewis
    Collaborator

    WDYT?

    Awesome! Thank you for your understanding!
    I really appreciate it!

    That sounds like a fantastic idea to me! 😁

  5. jferrl commented on Jun 1, 2024

    @jferrl
    ContributorAuthor

    WDYT?

    Awesome! Thank you for your understanding! I really appreciate it!

    That sounds like a fantastic idea to me! 😁

    Reading the readme carefully, I saw that someone had the same idea . https://github.com/google/go-github?tab=readme-ov-file#as-a-github-app (Sorry about creating the issue without reading deep 🤦‍♂️)

    This pkg has a different approach, just creating a custom http Transport instead of reusing oauth2 pkg interfaces.
    https://github.com/bradleyfalzon/ghinstallation

    Does it makes sense to mention two different ways to solve it in the readme ? WDYT?

  6. gmlewis commented on Jun 1, 2024

    @gmlewis
    Collaborator

    Does it makes sense to mention two different ways to solve it in the readme ? WDYT?

    Yes, absolutely, then people can choose. I'm wholeheartedly for it. Thank you!

  7. jferrl commented on Jun 1, 2024

    @jferrl
    ContributorAuthor

    Does it makes sense to mention two different ways to solve it in the readme ? WDYT?

    Yes, absolutely, then people can choose. I'm wholeheartedly for it. Thank you!

    Hi @gmlewis! 😃

    Here you have a new PR to update the README:

    #3180

  8. added a commit that references this issue on Jun 1, 2024
    446a296
  9. added a commit that references this issue on Jun 28, 2026
    a8865e7
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions