Skip to main content

Enterprise Server 3.15 は、現在リリース候補として使用できます。

ユーザーに代わって 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」を参照してください。