Авторизация учетных данных для единого входа с помощью приложения GitHub

Сведения о авторизации учетных данных с помощью GitHub App

По умолчанию установленное GitHub Apps предприятие не может авторизовать учетные данные. Чтобы сократить количество раз, когда участники предприятия должны авторизовать одни и те же учетные данные для отдельных организаций, можно разрешить приложению авторизовать существующие personal access tokens (classic) или проверенные ключи проверки подлинности SSH. Для каждого запроса разрешено до 50 выбранных организаций.

Чтобы авторизовать учетные данные для одной организации без GitHub Appнее, см. раздел AUTOTITLE или AUTOTITLE.

Prerequisites

Прежде чем приложение сможет авторизовать учетные данные, необходимо выполнить следующие требования:

Предприятие должно использовать единый вход на уровне предприятия.
Владелец учетных данных должен быть членом каждой организации, в которой приложение будет авторизовать учетные данные.

Создание GitHub App

Зарегистрируйте новое приложение. Инструкции см. в разделе Регистрация приложения GitHub. Приложение должно:
- Владеет предприятием или организацией в организации предприятия.
- Иметь доступ на запись к разрешению "Корпоративные учетные данные".
Обратите внимание на идентификатор клиента приложения, а затем создайте и безопасно сохраните закрытый ключ. См . раздел AUTOTITLE.
Установите приложение в вашей корпоративной учетной записи. См . раздел AUTOTITLE.
В URL-адресе страницы установки приложения обратите внимание на идентификатор установки. Идентификатор — это строка чисел в конце /enterprises/ENTERPRISE/settings/installations/ID URL-адреса.

Разрешение GitHub App авторизации учетных данных

Перейдите к своему предприятию. Например, на странице Enterprises на GitHub.com.
В разделе Settings, щелкните "Безопасность проверки подлинности".
В разделе "Учетные данные" включите разрешение GitHub Apps на авторизацию учетных данных.

Создание маркера доступа к установке

Приложение должно использовать маркер доступа к корпоративной установке для проверки подлинности запросов API. Маркеры доступа к установке организации, маркеры доступа пользователей и personal access tokens не поддерживаются.

Чтобы создать маркер доступа к установке, выполните приведенные далее действия.

Используйте идентификатор клиента и закрытый ключ приложения для создания веб-маркера JSON (JWT). См . раздел AUTOTITLE.
Используйте идентификатор JWT и корпоративную установку для создания маркера доступа к установке. См . раздел AUTOTITLE.

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

Поиск идентификаторов учетных данных

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

В ответе используйте authorized_credential_id ключ personal access token (classic)SSH или fingerprint для ключа SSH. Не используйте credential_id, идентифицирующее авторизацию учетных данных для этой организации.

Эта конечная точка не возвращает учетные данные, которые не были авторизованы для организации. Чтобы получить идентификатор для других учетных данных, используйте один из следующих методов:

Для параметра personal access token (classic)откройте маркер на странице параметров токена . Идентификатор маркера /settings/tokens/ID — это номер в конце URL-адреса. Кроме того, если маркер использовался для действия, записанного в журнале аудита предприятия, владелец предприятия может найти идентификатор в поле события token_id . Идентификатор доступен в журнале аудита только в то время как событие, отображаемое предприятием, прошедшее проверку подлинности с помощью этого маркера, сохраняется. Поделиться идентификатором, а не значением маркера. Дополнительные сведения см. в разделе [AUTOTITLE и Управление личными маркерами доступа](/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/searching-the-audit-log-for-your-enterprise).
Для ключа SSH найдите отпечаток SHA-256 для проверенного ключа проверки подлинности, принадлежащей пользователю. Дополнительные сведения см. в разделе Проверка ключей SSH.

Авторизация учетных данных

Используйте REST API для авторизации учетных данных для выбранных организаций. Рассмотрим пример.

curl --request POST \
  --url "https://api.github.com/enterprises/ENTERPRISE/credential-authorizations" \
  --header "Accept: application/vnd.github+json" \
  --header "Authorization: Bearer INSTALLATION-ACCESS-TOKEN" \
  --header "X-GitHub-Api-Version: 2026-03-10" \
  --data '{
    "credential_id": 12345678,
    "credential_type": "classic_pat",
    "organizations": ["ORGANIZATION-1", "ORGANIZATION-2"]
  }'

Замените ENTERPRISE корпоративным slug, INSTALLATION-ACCESS-TOKEN маркером доступа к установке и ORGANIZATION-1``ORGANIZATION-2 сбоем организации. Замените 12345678 идентификатором объекта personal access token (classic). Чтобы авторизовать ключ SSH, замените 12345678 его отпечатком SHA-256 и замените classic_pat на ssh_keyнего.

Дополнительные сведения см. в разделе Конечные точки REST API для авторизации учетных данных предприятия.

Отключение авторизации учетных данных с помощью GitHub Apps

Отключение параметра запрещает приложениям создавать новые авторизации учетных данных. Существующие авторизации остаются активными до тех пор, пока они не отозваны, учетные данные отозваны или удалены, или владелец учетных данных теряет членство в организации.

С помощью того же REST API можно отменить авторизацию, созданную приложением с помощью корпоративного делегирования.

Авторизация учетных данных для единого входа с помощью приложения GitHub

Кто может использовать эту функцию?

В этой статье