Github App Connexion Flow

Hi everyone :slight_smile: !

I’m developing a web app that will connect to Github repos of certain organizations and that will make some analytics on some of their repos.

After realizing that OAuth apps don’t allow for specific repos scope, I decided to switch to Github apps. My comprehension on the web app flow is the following:

  1. The member of the org decides to install the app on some of the repos and goes to the github app page and requests installation on the selected repos to the owner of the org
  2. Once it’s validated, he/she can go on the web app and via a github connect, the web app gets an access token of the user.
  3. From there, two options:
    3a) Either the web app uses user-to-server requests and uses the provided access token to make calls to the Github API
    3b) Or the web app requests an access token as an app (JWT token) and uses the provided access token to make server-to-server calls to Github API (probably better when it comes to rate limiting).

I have some questions for you guys:

  1. Am I correct in my understanding of the github app flow?
  2. Am I correct in thinking that it’s better to request an access token for server-to-server requests instead of user-to-server?
  3. If that’s the case, is my way of doing it the correct one: once I have the user access token, I check his/her installation id and get an access token corresponding to his/her installation?
  4. I also have a question regarding the expiration time: By default it’s one hour, but it’s likely that I will need more than this. Plus I will have a job that will reanalyze every day automatically the repos. How can I deal with getting a new token and a longer expiration time?

That’s a lot of questions, thanks if you can answer :slight_smile:

Regards,

JM

1 Like

:wave: hello there @jmomarty, and welcome to the GitHub Support Community!

Of the three steps, (1) is accurate. For (2) and (3), assuming that web app is the GitHub App and github connect is the authorization granted by either an owner or a GitHub App manager for an application to be installed on one or more of the organization’s repositories, the application can authenticate as an installation and make requests scoped to the repository (or repositories) it’s installed on. Making a request with an installation token is also known as a server-to-server request.

On the other hand, an application can only perform actions on behalf of a user if a user goes through the web application flow described in the Identifying and authorizing users for GitHub Apps article. User-to-server requests can be made once a user identifies the user and this gives the application the ability to create a user access token to access certain supported endpoints that may not otherwise be available using just an installation token.

It depends on the data you’re interested in accessing. In addition to the support endpoints for user access tokens, it may also be worth checking out the endpoints available per permission granted to a GitHub App in this guide: Permissions required for GitHub Apps.

Once you have the user access token, you can check which installation’s resources a user can access––that documentation also includes some information for checking which repositories are accessible to a user for an installation.

If you pursue the installation token (server-to-server) route, the documentation for the Installations API may be worth consulting here, specifically the endpoint for listing which repositories are accessible to the app installation.

:clap: This is a fantastic question! There’s not a way to configure a longer expiration period than one hour for an installation access token. However, you can use a JWT to create a new installation access token for the application. For user-to-server access tokens, I suggest checking out this guide for refreshing user-to-server access tokens.

I hope this helps! Would you like to know anything more about this topic?

1 Like