REST API に対する認証

認証について

多くの REST API エンドポイント操作では、認証が必要であるか、認証されている場合は追加情報が返されます。さらに、認証されている場合は 1 時間あたりの要求を増やすことができます。

要求を認証するには、必要なスコープまたはアクセス許可を持つ認証トークンを提供する必要があります。トークンを取得するには、いくつかの方法があります。personal access tokenを作成したり、GitHub Appでトークンを生成したり、GITHUB_TOKENワークフローで組み込みのGitHub Actionsを使用したりできます。

トークンを作成すると、要求の Authorization ヘッダーでトークンを送信することで要求を認証できます。たとえば、次の要求では、YOUR-TOKEN をトークンへの参照に置き換えます。

curl --request GET \
--url "https://api.github.com/octocat" \
--header "Authorization: Bearer YOUR-TOKEN" \
--header "X-GitHub-Api-Version: 2026-03-10"

メモ

ほとんどの場合は、Authorization: Bearer または Authorization: token を使用してトークンを渡すことができます。ただし、JSON Web トークン (JWT) を渡す場合は、Authorization: Bearer を使用する必要があります。

トークンなしで、またはアクセス許可が不十分なトークンで REST API エンドポイントを使用しようとすると、404 Not Found または 403 Forbidden 応答を受け取ります。無効な資格情報で認証すると、401 Unauthorized 応答が返されます。

無効な資格情報を含むリクエストを短期間に複数回検出すると、API は、403 Forbidden 応答で、そのユーザに対するすべての認証試行 (有効な資格情報による試行を含む) を一時的に拒否します。詳しくは、「REST API のレート制限」をご覧ください。

personal access tokenを使用した認証の実行

個人用に GitHub REST API を使用する場合は、 personal access tokenを作成できます。可能であれば、GitHubはfine-grained personal access tokenではなくpersonal access token (classic)を使用することをお勧めします。 personal access tokenの作成の詳細については、「個人用アクセストークンを管理する」を参照してください。

fine-grained personal access tokenを使用している場合、各 REST API エンドポイントにアクセスするには、fine-grained personal access tokenに特定のアクセス許可が必要です。各エンドポイントの REST API リファレンスドキュメントでは、エンドポイントが fine-grained personal access tokenで動作するかどうかを示し、トークンがエンドポイントを使用するために必要なアクセス許可を示します。一部のエンドポイントでは複数のアクセス許可が必要な場合があり、一部のエンドポイントでは複数のアクセス許可のうちの 1 つが必要な場合があります。各アクセス許可で fine-grained personal access token がアクセスできる REST API エンドポイントの概要については、詳細に制御された個人用アクセストークンに必要なアクセス許可を参照してください。

personal access token (classic)を使用している場合は、各 REST API エンドポイントにアクセスするために特定のスコープが必要です。選択するスコープに関する全般的なガイダンスについては、「OAuth アプリのスコープ」を参照してください。

Personal access tokens は、REST API に要求を行うときに ID として機能します (選択したスコープまたはアクセス許可によって制限されます)。そのため、 personal access tokens をセキュリティで保護することが重要です。 personal access tokensのセキュリティ保護の詳細については、「API 資格情報をセキュリティで保護する」を参照してください。

Personal access tokens と SAML SSO

認証に SAML シングルサインオン (SSO) を適用する組織にアクセスするために personal access token (classic) を使用する場合は、作成後にトークンを承認する必要があります。 Fine-grained personal access tokenは、組織へのアクセスが許可される前に、トークンの作成時に承認されます。詳しくは、「シングルサインオンに使用する個人用アクセストークンの認可」をご覧ください。

SAML SSO を適用する単一の組織にアクセスする前に SAML SSO の personal access token (classic) を承認しないと、 404 Not Found または 403 Forbidden エラーが発生する可能性があります。 403 Forbidden エラーが発生した場合、X-GitHub-SSO ヘッダーには、トークンを承認するために従うことができる URL が含まれます。 URL は 1 時間後に期限切れになります。

SAML SSO の personal access token (classic) を使用して複数の組織にアクセスしようとする前に承認しない場合、API は SAML SSO を必要とする組織からの結果を返しません。 X-GitHub-SSO ヘッダーには、 personal access token (classic)の SAML SSO 承認を必要とする組織の ID が示されます。例: X-GitHub-SSO: partial-results; organizations=21955855,20582480。

アプリによって生成されたトークンを使用した認証

組織または別のユーザーの代わりに API を使用する場合は、GitHubGitHub Appを使用することをお勧めします。詳しくは、「GitHub アプリでの認証について」をご覧ください。

各エンドポイントの REST API リファレンスドキュメントでは、エンドポイントが GitHub Apps で動作するかどうかを示し、アプリがエンドポイントを使用するために必要なアクセス許可を示しています。一部のエンドポイントでは複数のアクセス許可が必要な場合があり、一部のエンドポイントでは複数のアクセス許可のうちの 1 つが必要な場合があります。各アクセス許可で GitHub App がアクセスできる REST API エンドポイントの概要については、 GitHub Apps に必要なアクセス許可を参照してください。

REST API にアクセスするための OAuth app を使用して OAuth トークンを作成することもできます。ただし、 GitHub では、代わりに GitHub App を使用することをお勧めします。 GitHub Apps を使用すると、アプリが持つアクセスとアクセス許可をより詳細に制御できます。

アプリによって作成されたアクセストークンは、SAML SSO に対して自動的に承認されます。

基本認証を使用する

GitHub AppsおよびOAuth appsの一部の REST API エンドポイントでは、基本認証を使用してエンドポイントにアクセスする必要があります。ユーザー名としてアプリのクライアント ID を使用し、パスワードとしてアプリのクライアントシークレットを使用します。

次に例を示します。

curl --request POST \
--url "https://api.github.com/applications/YOUR_CLIENT_ID/token" \
--user "YOUR_CLIENT_ID:YOUR_CLIENT_SECRET" \
--header "Accept: application/vnd.github+json" \
--header "X-GitHub-Api-Version: 2026-03-10" \
--data '{
  "access_token": "ACCESS_TOKEN_TO_CHECK"
}'

クライアント ID とクライアントシークレットは、アプリの所有者またはアプリを承認したユーザーではなく、アプリに関連付けられます。アクセストークンの作成など、アプリに代わって操作を実行するために使用されます。

GitHub AppまたはOAuth appの所有者である場合、またはGitHub Appのアプリマネージャーである場合は、アプリの設定ページでクライアント ID を見つけてクライアントシークレットを生成できます。アプリの設定ページに移動するには:

GitHubのページの右上隅にあるプロフィール画像をクリックします。
アカウント設定にアクセスしてください。
- 個人用アカウントが所有するアプリの場合は、[設定] をクリックします。
- 組織が所有するアプリの場合: 1. [自分の組織] をクリックします。
  1. 組織の右側にある [設定] をクリックします。
左側のサイドバーの [Developer settings] をクリックします。
左側のサイドバーで、[ GitHub Apps ] または [ OAuth apps] をクリックします。
GitHub Appsの場合は、アクセスするGitHub Appの右側にある [編集] をクリックします。 OAuth appsの場合は、アクセスするアプリをクリックします。
[クライアント ID] の横に、アプリのクライアント ID が表示されます。
[クライアントシークレット] の横にある [新しいクライアントシークレットの生成] をクリックして、アプリのクライアントシークレットを生成します。

GitHub Actions ワークフローでの認証

GitHub Actions ワークフローで API を使用する場合GitHubは、トークンを作成するのではなく、組み込みのGITHUB_TOKENで認証することをお勧めします。 GITHUB_TOKEN キーを使用して、permissions へのアクセス許可を付与できます。詳しくは、「ワークフローでの認証に GITHUB_TOKEN を使用する」をご覧ください。

これが不可能な場合は、トークンをシークレットとして格納し、 GitHub Actions ワークフローでシークレットの名前を使用できます。シークレットの詳細については、「GitHub Actions でのシークレットの使用」を参照してください。

GitHub Actions を使用した GitHub CLI ワークフローでの認証

GitHub Actionsを使用して、GitHub CLI ワークフロー内の API に対して認証済み要求を行うには、GITHUB_TOKENの値を環境変数として格納し、run キーワードを使用して GitHub CLIapi サブコマンドを実行します。 run キーワードについて詳しくは、「GitHub Actions　のワークフロー構文」をご覧ください。

次のワークフロー例では、PATH をエンドポイントのパスに置き換えます。パスの詳細については、 REST API を使用した作業の開始を参照してください。

jobs:
  use_api:
    runs-on: ubuntu-latest
    permissions: {}
    steps:
      - env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          gh api /PATH

`curl` を使用した GitHub Actions ワークフローでの認証

GitHub Actionsを使用して、curl ワークフロー内の API に対して認証された要求を行うには、GITHUB_TOKENの値を環境変数として格納し、run キーワードを使用して API にcurl要求を実行します。 run キーワードについて詳しくは、「GitHub Actions　のワークフロー構文」をご覧ください。

YAML

jobs:
  use_api:
    runs-on: ubuntu-latest
    permissions: {}
    steps:
      - env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          curl --request GET \
          --url "https://api.github.com/PATH" \
          --header "Authorization: Bearer $GH_TOKEN"

jobs:
  use_api:
    runs-on: ubuntu-latest
    permissions: {}
    steps:
      - env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          curl --request GET \
          --url "https://api.github.com/PATH" \
          --header "Authorization: Bearer $GH_TOKEN"

この記事で