Are you sure you want to delete this access key?
title | intro | redirect_from | versions |
---|---|---|---|
Migrating OAuth Apps to GitHub Apps | Learn about the advantages of migrating your {% data variables.product.prodname_oauth_app %} to a {% data variables.product.prodname_github_app %} and how to migrate an {% data variables.product.prodname_oauth_app %} that isn't listed on {% data variables.product.prodname_marketplace %}. | [/apps/migrating-oauth-apps-to-github-apps] | [{free-pro-team *} {enterprise-server *} {github-ae *}] |
This article provides guidelines for existing integrators who are considering migrating from an OAuth App to a GitHub App.
GitHub Apps are the officially recommended way to integrate with GitHub because they offer many advantages over a pure OAuth-based integration:
These guidelines assume that you have a registered OAuth App{% if currentVersion == "free-pro-team@latest" %} that may or may not be listed in GitHub Marketplace{% endif %}. At a high level, you'll need to follow these steps:
While the majority of REST API endpoints and GraphQL queries are available to GitHub Apps today, we are still in the process of enabling some endpoints. Review the available REST endpoints to ensure that the endpoints you need are compatible with GitHub Apps. Note that some of the API endpoints enabled for GitHub Apps allow the app to act on behalf of the user. See "User-to-server requests" for a list of endpoints that allow a GitHub App to authenticate as a user.
We recommend reviewing the list of API endpoints you need as early as possible. Please let Support know if there is an endpoint you require that is not yet enabled for {% data variables.product.prodname_github_app %}s.
GitHub Apps use sliding rules for rate limits, which can increase based on the number of repositories and users in the organization. A GitHub App can also make use of conditional requests or consolidate requests by using the GraphQL API V4.
Once you've decided to make the switch to GitHub Apps, you'll need to create a new GitHub App.
When registering your GitHub App, you'll need to select the permissions required by each endpoint used in your app's code. See "GitHub App permissions" for a list of the permissions needed for each endpoint available to GitHub Apps.
In your GitHub App's settings, you can specify whether your app needs No Access
, Read-only
, or Read & Write
access for each permission type. The fine-grained permissions allow your app to gain targeted access to the subset of data you need. We recommend specifying the smallest set of permissions possible that provides the desired functionality.
After you've created a new GitHub App and selected its permissions, you can select the webhook events you wish to subscribe it to. See "Editing a GitHub App's permissions" to learn how to subscribe to webhooks.
GitHub Apps primarily use a token-based authentication that expires after a short amount of time, providing more security than an OAuth token that does not expire. It’s important to understand the different methods of authentication available to you and when you need to use them:
The most common scenario is to authenticate as a specific installation using an installation access token.
Once you've made the transition from an OAuth App to a GitHub App, you will need to let users know that the GitHub App is available to install. For example, you can include an installation link for the GitHub App in a call-to-action banner inside your application. To ease the transition, you can use query parameters to identify the user or organization account that is going through the installation flow for your GitHub App and pre-select any repositories your OAuth App had access to. This allows users to easily install your GitHub App on repositories you already have access to.
Name | Description |
---|---|
suggested_target_id |
Required: ID of the user or organization that is installing your GitHub App. |
repository_ids[] |
Array of repository IDs. If omitted, we select all repositories. The maximum number of repositories that can be pre-selected is 100. |
https://github.com/apps/YOUR_APP_NAME/installations/new/permissions?suggested_target_id=ID_OF_USER_OR_ORG&repository_ids[]=REPO_A_ID&repository_ids[]=REPO_B_ID
You'll need to replace YOUR_APP_NAME
with the name of your GitHub App, ID_OF_USER_OR_ORG
with the ID of your target user or organization, and include up to 100 repository IDs (REPO_A_ID
and REPO_B_ID
). To get a list of repositories your OAuth App has access to, use the List repositories for the authenticated user and List organization repositories endpoints.
Once your GitHub App has been installed on a repository, you should remove any unnecessary webhooks that were created by your legacy OAuth App. If both apps are installed on a repository, they may duplicate functionality for the user. To remove webhooks, you can listen for the installation_repositories
webhook with the repositories_added
action and Delete a repository webhook on those repositories that were created by your OAuth App.
As your GitHub App installation base grows, consider encouraging your users to revoke access to the legacy OAuth integration.
Press p or to see the previous file or, n or to see the next file
Are you sure you want to delete this access key?
Are you sure you want to delete this access key?
Are you sure you want to delete this access key?
Are you sure you want to delete this access key?