Другие методы проверки подлинности

Хотя API предоставляет несколько методов проверки подлинности, для рабочих приложений настоятельно рекомендуется использовать OAuth. Другие методы предназначены для скриптов или тестирования (т. е. для случаев, когда возможности OAuth избыточны). Сторонние приложения, использующие GitHub для проверки подлинности, не должны запрашивать или собирать учетные данные GitHub. Вместо этого они должны использовать веб-поток OAuth.

Обычная проверка подлинности

API поддерживает обычную проверку подлинности согласно RFC2617 с небольшими отличиями. Основное отличие заключается в том, что согласно требованиям RFC на запросы, не прошедшие проверку подлинности, должен предоставляться ответ 401 Unauthorized. Во многих случаях это позволяет узнать о существовании пользовательских данных. Вместо этого API GitHub возвращает ответ 404 Not Found. Это может привести к проблемам при использовании библиотек HTTP, предполагающих ответ 401 Unauthorized. Решением может быть формирование заголовка Authorization вручную.

Через personal access tokens

Для проверки подлинности в API GitHub рекомендуется использовать fine-grained personal access tokens.

$ curl -u USERNAME:TOKEN https://api.github.com/user

Этот подход полезен, если ваши средства поддерживают только обычную проверку подлинности, но вы хотите воспользоваться преимуществами функций безопасности personal access token.

Имя пользователя и пароль

Примечание. На GitHub поддержка проверки пароля в API прекращена с 13 ноября 2020 г. для всех учетных записей GitHub.com, включая планы GitHub Free, GitHub Pro, GitHub Team и GitHub Enterprise Cloud. Теперь необходимо пройти проверку подлинности в API GitHub с помощью маркера API, например маркера доступа OAuth, маркера доступа для установки приложения GitHub или personal access token, в зависимости от того, что необходимо сделать с маркером. Дополнительные сведения см. в разделе Устранение неполадок.

Проверка подлинности для единого входа SAML

Примечание. Интеграции и приложения OAuth, которые создают токены от чьего-то имени, авторизуются автоматически.

Примечание. В большинстве случаев передать маркер с помощью Authorization: Bearer или Authorization: token. Однако при передаче веб-токена JSON (JWT) необходимо использовать Authorization: Bearer.

Если вы используете API для доступа к организации, которая применяет единый вход SAML для проверки подлинности, необходимо создать personal access token и авторизовать маркер для этой организации. Перейдите по URL-адресу, указанному в X-GitHub-SSO, чтобы авторизовать токен для организации.

$ curl -v -H "Authorization: Bearer TOKEN" https://api.github.com/repos/octodocs-test/test

> X-GitHub-SSO: required; url=https://github.com/orgs/octodocs-test/sso?authorization_request=AZSCKtL4U8yX1H3sCQIVnVgmjmon5fWxks5YrqhJgah0b2tlbl9pZM4EuMz4
{
  "message": "Resource protected by organization SAML enforcement. You must grant your personal token access to this organization.",
  "documentation_url": "https://docs.github.com"
}

При запросе данных, которые могут поступать из нескольких организаций (например, запрос списка проблем, созданных пользователем), X-GitHub-SSO заголовок указывает, какие организации требуют авторизовать personal access token:

$ curl -v -H "Authorization: Bearer TOKEN" https://api.github.com/user/issues

> X-GitHub-SSO: partial-results; organizations=21955855,20582480

Значение organizations представляет собой разделенный запятыми список идентификаторов организаций для организаций, требующих авторизации personal access token.

Работа с двухфакторной проверкой подлинности

Если включена двухфакторная проверка подлинности, обычная проверка подлинности для большинства конечных точек в REST API требует использования personal access token.

Вы можете создать новый personal access token с помощью параметров разработчика GitHub . Дополнительные сведения см. в разделе Создание personal access token для командной строки. Затем эти токены используются для проверки подлинности с помощью токена OAuth в API GitHub.