Skip to main content

このバージョンの GitHub Enterprise はこの日付をもって終了となります: 2023-01-18. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの向上、新機能の向上を図るために、最新バージョンの GitHub Enterprise にアップグレードします。 アップグレードに関するヘルプについては、GitHub Enterprise サポートにお問い合わせください

アプリケーションについて

GitHub Enterprise Server API でインテグレーションを構築し、柔軟性を強化して自分のワークフローの摩擦を軽減できます。

GitHub のアプリケーションを使用すると、ワークフローを自動化し改善できます。 アプリをビルドしてワークフローを改善できます。

GitHub Appsは、データへのアクセスについてより細やかな権限を提供することから、GitHubとのインテグレーションのための公式に推奨される方式ですが。ただし、GitHub は OAuth Apps と GitHub Apps の両方をサポートしています。 アプリの種類の選択については、「GitHub App と OAuth App の違い」を参照してください。

GitHub App をビルドする手順については、「最初の GitHub App のビルド」を参照してください。

GitHub Apps について

GitHub Apps は GitHub の中でも主役級の存在です。 GitHub App は独自で動作し、独自の ID を使用して API 経由で直接アクションを実行します。つまり、ボットやサービスアカウントを別途維持する必要がありません。

GitHub Apps は、Organization や個人アカウントに直接インストールでき、特定のリポジトリへのアクセス権を付与できます。 精細なアクセス権限が付いており、webhook が組み込まれています。 GitHub App をセットアップする際、アクセスさせるリポジトリを選択できます。 たとえば、リポジトリに問題を書き込み、リポジトリMyGitHubのみにoctocat き込むアプリをoctocat設定できます。 GitHub App をインストールするには、Organization のオーナーであるか、リポジトリで管理者権限を持っている必要があります。

デフォルトでは、Organization内のGitHub Appsの設定を管理できるのはOrganizationのオーナーだけです。 Organization内のGitHub Appsを管理できるユーザを追加するには、管理者がそのユーザにGitHub Appの管理者権限を許可します。 組織内の GitHub App マネージャーを追加および削除する方法については、「GitHub App マネージャー」を参照してください。

GitHub Apps は、どこかにホストする必要があるアプリケーションです。 サーバーとホスティングに関する詳しい手順については、「最初の GitHub App のビルド」をご覧ください。

ワークフローを改善するため、複数のスクリプトまたはアプリケーション全体を含む GitHub App を作成し、それをその他の数多くのツールと接続できます。 たとえば、GitHub Apps を GitHub、Slack、その他の社内アプリケーション、電子メールプログラム、その他の API などに接続できます。

GitHub Apps を作成する際は、以下に気を付けてください。

  • GitHub App は、(アプリがユーザーからサーバーへのトークンを使用している場合を除き) ユーザーに依存しないアクションを実行する必要があります。 ユーザからサーバーへのアクセストークンをさらにセキュアにするために、8時間後に期限切れとなるアクセストークンと、新しいアクセストークンと交換できるリフレッシュトークンを使用できます。 詳細については、「ユーザーからサーバーへのアクセス トークンの更新」を参照してください。

  • GitHub App は、必ず特定のリポジトリと統合するようにしてください。

  • GitHub App は個人アカウントまたは Organization に接続する必要があります。

  • ユーザができる全てのことを GitHub App が知り、行えるとは思わないでください。

  • 単に「GitHub でログイン」するサービスが必要な場合は、GitHub App を使用しないでください。 ただし、GitHub App では 、ユーザー識別フロー を使用してユーザーをログイン させ、 他の操作を実行できます。

  • GitHub ユーザーとして動作し、ユーザーが実行できることをすべて実行したい だけ の場合は、GitHub App をビルドしないでください。

GitHub Apps アプリケーションの開発を始めるには、「GitHub App の作成」から取りかかってください。

OAuth Apps について

OAuth2 は、外部アプリケーションがパスワードにアクセスすることなく、ユーザの GitHub アカウントの個人情報にアクセスする承認を要求できるようにするプロトコルです。 これは Basic 認証よりも好ましい方法です。なぜなら、トークンは特定の種類のデータに限定でき、ユーザがいつでも取り消すことができるからです。

警告: OAuth App からすべてのアクセス許可を取り消すと、ユーザーの代わりにアプリケーションで生成されたすべての SSH キー (デプロイ キーを含む) が削除されます。

OAuth App は、アプリケーションにアクセス権を付与するユーザを認証するため、アイデンティティプロバイダとして GitHub を使用します。 つまり、ユーザーが OAuth App アクセスを許可すると、ユーザーは自分のアカウントでアクセスできる すべての リポジトリにアクセス許可を付与します。また、サードパーティのアクセスをブロックしていない組織にもアクセス許可を付与します。

単純なスクリプトで処理できるよりも複雑なプロセスを作成する場合、OAuth App を構築するのは良い選択肢です。 OAuth Apps は、どこかにホストする必要があるアプリケーションであることに注意してください。

OAuth Apps を作成する際は、以下に気を付けてください。

  • OAuth App は、GitHub 全体にわたって、常に認証された GitHub ユーザとして振る舞う必要があります (たとえば、ユーザ通知を行う場合など)。
  • 認証されたユーザに対して「GitHub でログイン」を有効化することにより、OAuth App をアイデンティティプロバイダとして使用できます。
  • 単一のリポジトリで動作するアプリケーションが必要な場合、OAuth App を構築しないでください。 OAuth スコープを repo 使用すると、OAuth Apps は、認証 されたすべての ユーザーのリポジトリで動作できます。
  • Team や企業を代理するアプリケーションとして OAuth App を構築しないでください。 OAuth Apps は単一のユーザとして認証を行うので、ある人が OAuth App を会社が使用するものとして作成し、その人が会社を辞めた場合は、他の人がアクセスできなくなります。

OAuth Apps について詳しくは、「OAuth App の作成」および「アプリの登録」をご覧ください。

Personal access token

personal access tokenは、スコープを使用してそのアクセス許可を指定できる点で OAuth トークンと同様に機能する文字の文字列です。 また、personal access tokenはパスワードとも似ています。ただし、個人アクセストークンは複数所有でき、それぞれのアクセス権をいつでも取り消すことができます。

たとえば、personal access tokenにリポジトリへの書き込みをできるように設定できます。 そして、リポジトリで issue を作成する cURL コマンドを実行するかスクリプトを記述する場合、personal access tokenを渡して認証します。 personal access tokenを環境変数として保存することで、使用のたびに入力することを避けることができます。

personal access tokenを使用する場合は、次の点に注意してください。

  • トークンは自分自身のみを表すものとして使用してください。
  • 1 回限りの cURL リクエストを実行できます。
  • 個人用のスクリプトを実行できます。
  • Team や会社全体が使用するスクリプトは設定しないでください。
  • ボット ユーザーとして動作する共有ユーザー アカウントは設定しないでください。
  • トークンに必要な最小限の特権を付与します。
  • 情報をセキュリティで保護するために、personal access tokenの有効期限を設定します。

構築すべきインテグレーションを決定する

インテグレーションの作成に取りかかる前に、GitHub Enterprise Server API を使用したアクセス、認証、対話に最善の方法を見極める必要があります。 統合でpersonal access token、GitHub Apps、OAuth Apps のどれを使用するかを決める際の考慮事項を以下の画像に示しています。

アプリケーションの質問フローの紹介

インテグレーションがどう振る舞うべきか、何にアクセスできるべきかについては、以下の質問を検討してください。

  • インテグレーションは自分自身としてのみ振る舞うのか、それともアプリケーションのように振る舞うのか?
  • 独自のエンティティとして、自分から独立して動作させるのか?
  • 自分がアクセスできるもの全てにアクセスするのか、それともアクセスを制限するのか?
  • 単純か、それとも複雑か? たとえば、personal access tokenは単純なスクリプトや cURL に適し、OAuth App はより複雑なスクリプトを処理できます。

サポートのリクエスト

For questions, bug reports, and discussions about GitHub Apps, OAuth Apps, and API development, explore the GitHub コミュニティでの API と統合に関するディスカッション. The discussions are moderated and maintained by GitHub staff, but questions posted to the forum are not guaranteed to receive a reply from GitHub staff.

Consider reaching out to GitHub Support directly using the contact form for:

  • guaranteed response from GitHub Enterprise Server staff
  • support requests involving sensitive data or private concerns
  • feature requests
  • feedback about GitHub Enterprise Server products