Skip to main content

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

ユーザーに代わって GitHub アプリで認証する

GitHub App は、issue の作成、コメントの投稿、デプロイの作成などのアクションをユーザーの代わりに実行できます。

アプリは、ユーザーに代わって API 要求を行うことができます。 アプリがユーザーに代わって行った API 要求は、そのユーザーに帰属します。 たとえば、アプリがユーザーに代わってコメントを投稿した場合、GitHub UI には、ユーザーのアバター写真とアプリのアイデンティコン バッジがイシューの作成者として表示されます。

アプリのアイデンティコン バッジがオーバーレイされたユーザー アバターがあるコメントのスクリーンショット。 アバターがオレンジ色の枠線で強調表示されています。

同様に、要求によって監査ログとセキュリティ ログ内の対応するエントリがトリガーされた場合、ログにはユーザーがアクターとして一覧表示されますが、"programmatic_access_type" が "GitHub App user-to-server token" であると示されます。

ユーザーに代わって API 要求を行うには、ユーザーがアプリを承認する必要があります。 複数のメンバーを含む Organization にアプリがインストールされている場合は、アプリがメンバーに代わって動作する前に、各メンバーがアプリを承認する必要があります。 ユーザーがアプリを承認するためにアプリをインストールする必要はありません。

ユーザーは、自分のアカウントまたは Organization にアプリをインストールするときに、要求された Organization とリポジトリのリソースにアクセスするためのアクセス許可をアプリに付与します。 インストール プロセスの間に、アプリが個々のユーザーに対して要求できるアカウント アクセス許可の一覧も表示されます。 ユーザーは、アプリを承認するときに、ユーザーの代わりに動作するためのアクセス許可をアプリに付与し、アプリから要求されたアカウント アクセス許可を付与します。

ユーザーがアプリを承認したら、OAuth トークンの一種であるユーザー アクセス トークンを生成できます。 後続の API 要求の Authorization ヘッダーにあるユーザー アクセス トークンを送信する必要があります。 ユーザーにアプリの承認を求め、ユーザー アクセス トークンを生成する方法について詳しくは、「GitHub アプリのユーザー アクセス トークンの生成」を参照してください。

ユーザー アクセス トークンを使用して行われた要求は、"ユーザーからサーバーへの" 要求と呼ばれることもあります。

アプリのアクティビティをユーザーではなくアプリに帰属させる場合は、代わりにアプリのインストールとして認証する必要があります。 詳しくは、「GitHub App インストールとしての認証」を参照してください。

: GitHub App を承認した後に自分の Organization で所有しているリソースを表示できないことがユーザーから報告され、その Organization で SAML SSO を使用している場合、再認証する前に、Organization のアクティブな SAML セッションを開始するようにユーザーに指示します。 詳しい情報については、GitHub Enterprise Cloud ドキュメントの「SAML と GitHub Apps」を参照してください。