Проверка подлинности в REST API

Об аутентификации

Для многих конечных точек REST API требуется проверка подлинности или возврат дополнительных сведений при проверке подлинности. Кроме того, при проверке подлинности можно выполнять больше запросов в час.

Чтобы выполнить проверку подлинности запроса, необходимо предоставить маркер проверки подлинности с необходимыми областями или разрешениями. Есть несколько способов получить токен: вы можете создать 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 (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 рекомендуется использовать a fine-grained personal access token вместо personal access token (classic). Для получения дополнительной информации о создании personal access token, см. Управление личными маркерами доступа.

Если вы используете, fine-grained personal access token для доступа к каждой конечной fine-grained personal access tokenточке REST API требуются определенные разрешения. В справочном документе REST API для каждого конечного пункта указано, работает ли конечная точка с fine-grained personal access tokenS, и указывает, какие разрешения необходимы для использования токена. Для некоторых конечных точек может потребоваться несколько разрешений, а для некоторых конечных точек может потребоваться одно из нескольких разрешений. Для обзора того, к которым REST API fine-grained personal access token может получить доступ с каждым разрешением, см. Разрешения, необходимые для подробных персональных маркеров доступа.

Если используется, для доступа к каждой конечной personal access token (classic)точке REST API требуются определенные области. Общие рекомендации по выбору областей см. в разделе Области для приложений OAuth.

Personal access tokens действует как удостоверение (ограничено выбранными областями или разрешениями) при выполнении запросов к REST API. Таким образом, важно обеспечить personal access tokens безопасность. Дополнительные сведения о защите personal access tokens см. в разделе Обеспечение безопасности учетных данных API.

Personal access tokens единый вход и SAML

Если вы используете personal access token (classic) для доступа к организации, которая применяет единый вход SAML для проверки подлинности, вам потребуется авторизовать маркер после создания. Fine-grained personal access tokenS авторизованы во время создания токена, до предоставления доступа к организации. Дополнительные сведения см. в разделе Авторизация личного маркера доступа для использования с единым входом.

Если вы не авторизуете единый personal access token (classic) вход SAML, прежде чем пытаться использовать его для доступа к одной организации, которая применяет единый вход SAML, вы можете получить 404 Not Found или ошибку 403 Forbidden . Если вы получите ошибку 403 Forbidden, заголовок X-GitHub-SSO будет содержать URL, по которому вы можете перейти для авторизации токена. Срок действия URL-адреса истекает через час.

Если вы не авторизуете personal access token (classic) единый вход SAML, прежде чем пытаться использовать его для доступа к нескольким организациям, API не вернет результаты из организаций, требующих единого входа SAML, и X-GitHub-SSO заголовок будет указывать идентификатор организаций, которым требуется авторизация единого personal access token (classic)входа SAML. Например: X-GitHub-SSO: partial-results; organizations=21955855,20582480.

Проверка подлинности с помощью маркера, созданного приложением

Если вы хотите использовать API для организации или от имени другого пользователя, GitHub рекомендуется использовать .GitHub App Дополнительные сведения см. в разделе Об аутентификации с помощью приложения GitHub.

Справочная документация по REST API для каждой конечной точки указывает, работает ли конечная точка и GitHub Apps указывает, какие разрешения необходимы для использования конечной точкой приложения. Для некоторых конечных точек может потребоваться несколько разрешений, а для некоторых конечных точек может потребоваться одно из нескольких разрешений. Для обзора того, к которым REST API GitHub App может получить доступ с каждым разрешением, см. Для приложений GitHub требуются права.

Вы также можете создать токен OAuth с OAuth app помощью доступа к REST API. Однако GitHub рекомендуется использовать вместо этого GitHub App . GitHub Apps Это позволяет больше контролировать доступ и разрешения, которые есть приложение.

Маркеры доступа, созданные приложениями, автоматически авторизованы для единого входа SAML.

Использование обычной аутентификации

Для некоторых конечных GitHub AppsOAuth apps точек REST API и требуется использовать базовую проверку подлинности для доступа к конечной точке. Идентификатор клиента приложения будет использоваться в качестве имени пользователя и секрета клиента приложения в качестве пароля.

Например:

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"
}'

Идентификатор клиента и секрет клиента связаны с приложением, а не с владельцем приложения или пользователем, авторизованным приложением. Они используются для выполнения операций от имени приложения, например создания маркеров доступа.

Если вы являетесь владельцем GitHub App или OAuth app, или если вы являетесь диспетчером приложений для приложения GitHub App, вы можете найти идентификатор клиента и создать секрет клиента на странице параметров приложения. Чтобы перейти на страницу параметров приложения, выполните следующие действия.

В правом верхнем углу любой страницы на GitHub, нажмите на свою фотографию профиля.
Перейдите к настройкам учетной записи.
- Для приложения, принадлежащих личная учетная запись, нажмите кнопку "Параметры".
- Для приложения, принадлежащих организации:
  1. Щелкните Your organizations (Ваши организации).
  2. Справа от организации нажмите кнопку "Параметры".
На левой боковой панели щелкните Параметры разработчика.
В левой боковой панели щелкните GitHub Apps или OAuth apps.
В GitHub Appsправой части нужного GitHub App доступа нажмите кнопку "Изменить". Для OAuth appsэтого щелкните приложение, к которому требуется получить доступ.
Рядом с идентификатором клиента вы увидите идентификатор клиента для приложения.
Рядом с секретами клиента нажмите кнопку "Создать новый секрет клиента", чтобы создать секрет клиента для приложения.

Проверка подлинности в GitHub Actions рабочем процессе

Если вы хотите использовать API в рабочем GitHub Actions процессе, GitHub рекомендую аутентифицироваться встроенным GITHUB_TOKEN токеном, а не создавать токена. Вы можете предоставить разрешения для GITHUB_TOKEN с помощью ключа permissions. Дополнительные сведения см. в разделе Использование GITHUB_TOKEN для проверки подлинности в рабочих процессах.

Если это невозможно, вы можете сохранить маркер в качестве секрета и использовать имя секрета в GitHub Actions рабочем процессе. Дополнительные сведения о секретах см. в разделе Использование секретов в GitHub Actions.

Проверка подлинности в GitHub Actions рабочем процессе с помощью GitHub CLI

Чтобы выполнить прошедший проверку подлинности запрос к API в рабочем процессе, GitHub Actionsможно сохранить значение GITHUB_TOKEN в GitHub CLI качестве переменной среды и использовать 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

Проверка подлинности в GitHub Actions рабочем процессе с помощью `curl`

Чтобы выполнить прошедший проверку подлинности запрос к API в рабочем процессе, curlможно сохранить значение GITHUB_TOKEN в GitHub Actions качестве переменной среды и использовать run ключевое слово для выполнения curl запроса к API. Дополнительные сведения о ключевом слове 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"

Проверка подлинности в REST API

В этой статье