Управление личными маркерами доступа

О personal access tokens

          Personal access tokens являются альтернативой использованию паролей для аутентификации при GitHub[использованииGitHub API](/rest/overview/authenticating-to-the-rest-api) или [командной строки](#using-a-personal-access-token-on-the-command-line).

          Personal access tokenS предназначены для доступа к GitHub ресурсам от вашего имени. Чтобы получить доступ к ресурсам от имени организации или для долгосрочных интеграций, следует использовать GitHub App. Дополнительные сведения см. в разделе [AUTOTITLE](/apps/creating-github-apps/setting-up-a-github-app/about-creating-github-apps).

          Маркер имеет те же возможности для доступа к ресурсам и выполнения действий с этими ресурсами, которые владелец маркера имеет, и дополнительно ограничивается любыми областями или разрешениями, предоставленными маркеру. Маркер не может предоставить пользователю дополнительные возможности доступа. Например, a personal access token может быть настроен с `admin:org` областью применения, но если владелец токена не является владельцем организации, токен не предоставит административный доступ организации.

Типы personal access token

          GitHub В настоящее время поддерживает два типа personal access tokenS: fine-grained personal access tokenS и personal access tokens (classic). 
          GitHub Рекомендует использовать fine-grained personal access tokenS вместо personal access tokens (classic) S, когда это возможно.

Оба s fine-grained personal access tokenи personal access tokens (classic) связаны с пользователем, который их сгенерировал, и станут неактивными, если пользователь потеряет доступ к ресурсу.

Владельцы организаций могут установить политику, ограничивающую доступ personal access tokens (classic) к своей организации, а владельцы предприятий могут ограничивать доступ personal access tokens (classic) к предприятиям или организациям, принадлежащим предприятиям. Дополнительные сведения см. в разделе Настройка политики личного маркера доступа для вашей организации.

Fine-grained personal access tokens

          Fine-grained personal access tokens У них есть несколько преимуществ personal access tokens (classic)в безопасности, но также есть ограничения, которые могут помешать вам использовать их в любой ситуации. Эти ограничения и наши планы по их устранению см. в [разделе ниже](#fine-grained-personal-access-tokens-limitations).

Если вы сможете использовать A fine-grained personal access token для своего сценария, вы получите пользу от следующих улучшений:

• Каждый маркер ограничен доступом к ресурсам, принадлежащим одному пользователю или организации.
• Каждый маркер может быть ограничен только определенными репозиториями для этого пользователя или организации.
• Каждому токена предоставляются конкретные, детализированные разрешения, которые дают больше контроля, чем область применения, предоставленная personal access tokens (classic).
• Владельцы организаций могут потребовать одобрение для любых fine-grained personal access tokenорганизаций, имеющих доступ к ресурсам организации.
• Владельцы предприятий могут потребовать одобрения для любых fine-grained personal access tokenорганизаций, которые имеют доступ к ресурсам в организациях, принадлежащих предприятиям.

Fine-grained personal access tokens Ограничения

          Fine-grained personal access tokensНе поддерживайте все функции .personal access tokens (classic) Эти пробелы в особенностях не постоянны — GitHub он работает над их закрытием. Вы можете просмотреть [нашу общедоступную стратегию](https://github.com/github/roadmap) для получения дополнительных сведений о том, когда эти сценарии будут поддерживаться.

Основные пробелы в fine-grained personal access tokens следующие:

• Используется fine-grained personal access token для внесения вклада в публичные репозитории, где пользователь не является участником.

• Используется fine-grained personal access token для внесения вклада в репозитории, где пользователь является внешним или репозиториевым соавтором.

• Использовать fine-grained personal access token доступ к нескольким организациям одновременно.

          * Использование fine-grained personal access token доступа `internal` к ресурсам внутри предприятия, к которому принадлежит пользователь.
  

• Использую fine-grained personal access token вызов API, управляющих корпоративной учетной записью.

          * Использование fine-grained personal access token для доступа к пакетам.
  

• Использую fine-grained personal access token вызов API проверок.

• Используйте fine-grained personal access token доступ к проектам, принадлежащим пользовательской учетной записи.

Все эти пробелы будут устранены со временем, поскольку GitHub мы продолжаем инвестировать в более безопасные модели доступа.

Personal access tokens (classic)

Personal access tokens (classic) менее безопасны. Однако некоторые функции в настоящее время будут работать только с personal access tokens (classic):

• Только personal access tokens (classic) имеют доступ на запись для общедоступных репозиториев, которые не принадлежат вам или организации, в которую вы не входите.
• Только personal access tokens (classic) автоматически имеют доступ на запись для внутренних репозиториев, принадлежащих вашей организации. Fine-grained personal access tokens необходимо предоставить доступ к внутренним репозиториям.
• Внешние сотрудники могут использовать только personal access tokens (classic) для доступа к репозиториям организации, над которыми они находятся.
• Доступ к предприятиям может получить только personal access tokens (classic). (Fine-grained personal access token может получить доступ к организациям, принадлежащим предприятиям.)
• Несколько конечных точек REST API доступны только с помощью personal access tokens (classic). Чтобы проверить, поддерживает ли конечная точка fine-grained personal access tokens, ознакомьтесь с документацией по этой конечной точке или см. раздел AUTOTITLE.

Если вы решите использовать personal access token (classic), имейте в виду, что он предоставит доступ ко всем репозиториям внутри организаций, к которым у вас есть доступ, а также ко всем личным репозиториям в вашем личном аккаунте.

Как сохранить свою personal access tokenбезопасность

          Personal access tokenS — это как пароли, и они несут одинаковые врождённые риски безопасности. Перед созданием нового personal access tokenаккаунта подумайте, есть ли более безопасный способ аутентификации:

• Чтобы получить доступ GitHub из командной строки, можно использовать GitHub CLI или Git Credential Manager вместо создания personal access token.
• При использовании personal access token a в рабочем GitHub Actions процессе подумайте, можно ли использовать встроенный GITHUB_TOKEN процесс. Дополнительные сведения см. в разделе Использование GITHUB_TOKEN для проверки подлинности в рабочих процессах.

Если эти варианты невозможны, и вам нужно создать personal access token, рассмотрите возможность использования другого сервиса CLI для безопасного хранения вашего токена.

При использовании a personal access token в скрипте вы можете хранить свой токен как секрет и запускать скрипт через GitHub Actions. Для получения дополнительной информации см. Использование секретов в GitHub Actions.

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

Создание fine-grained personal access token

1. В правом верхнем углу любой страницы на GitHubщелкните рисунок профиля, а затем выберите октикона "шестеренка" aria-hidden="true" aria-label="gear" %} Settings.

2. На левой боковой панели щелкните Параметры разработчика.

3. В левой боковой панели, под Personal access tokens, нажмите Тонкозернистые жетоны.

4. Нажмите кнопку "Создать новый маркер".

5. В разделе "Имя токена" введите имя маркера.

6. В разделе "Срок действия" выберите срок действия маркера. Бесконечное время существования разрешено, но может быть заблокировано максимальной политикой времени существования, установленной вашей организацией или владельцем предприятия. Для получения дополнительной информации см. раздел «Обеспечение применения максимальной пожизненной политики» для personal access tokens.

7. При необходимости в разделе "Описание" добавьте заметку, чтобы описать назначение маркера.

8. В разделе "Владелец ресурса" выберите владельца ресурса. Маркер сможет получить доступ только к ресурсам, принадлежащим выбранному владельцу ресурса. Организации, членом которых вы являетесь, не появятся, если организация заблокировала использование fine-grained personal access tokens. Для получения дополнительной информации см. Настройка политики личного маркера доступа для вашей организации.

9. Опционально, если владелец ресурса — организация, требующая одобрения для fine-grained personal access tokens, ниже владельца ресурса в поле введите обоснование запроса.

10. В разделе "Доступ к репозиторию" выберите репозитории, к которым требуется получить доступ. Вы должны выбрать минимальный доступ к репозиторию, соответствующий вашим потребностям. Токены всегда включают доступ только для чтения ко всем публичным репозиториям на GitHub.

11. Если вы выбрали только репозитории на предыдущем шаге, в раскрывающемся списке "Выбранные репозитории " выберите репозитории, к которым требуется получить доступ маркера.

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

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

13. Щелкните Создать токен.

Если вы выбрали организацию в качестве владельца ресурса и организация требует одобрения для fine-grained personal access tokens, то ваш токен будет отмечен как pending до тех пор, пока его не проверит администратор организации. Маркер сможет читать общедоступные ресурсы только до тех пор, пока он не будет утвержден. Если вы являетесь владельцем организации, ваш запрос автоматически утвержден. Дополнительные сведения см. в разделе Просмотр и отзыв персональных маркеров доступа в организации.

Предварительное заполнение fine-grained personal access token данных с использованием параметров URL

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

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

Ниже показан пример шаблона URL-адреса с разрывами строк для удобочитаемости:

https://github.com/settings/personal-access-tokens/new
  ?name=Repo-reading+token
  &description=Just+contents:read
  &target_name=octodemo
  &expires_in=45
  &contents=read

https://github.com/settings/personal-access-tokens/new
  ?name=Repo-reading+token
  &description=Just+contents:read
  &target_name=octodemo
  &expires_in=45
  &contents=read

Попробуйте создать маркер с contents:read``metadata:readуказанным именем и описанием и датой окончания срока действия 45 дней в будущем. Появится сообщение об ошибке, Cannot find the specified resource owner: octodemo указывающее, что вы не являетесь членом octodemo организации.

Ниже приведены некоторые примеры URL-адресов, которые создают маркеры, которые мы видим чаще всего:

• Чтение содержимого репозитория
• Отправка доступа к репозиториям
• GitHub Доступ к моделям
• Обновление кода и открытие PR
• Управление Copilot лицензиями в организации
• Сделать Copilot запросы

Поддерживаемые параметры запроса

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

          `30` или `none` | Целое число от 1 до 366 или `none` | Дни до истечения срока действия или `none` истечения срока действия. Если это не указано, значение по умолчанию равно 30 дней или меньше, если целевой объект имеет набор политик времени существования маркера. |

| <permission> | строка | contents=read | Ряд уровней разрешений и доступа. | Разрешения, которые должен иметь маркер. Разрешения могут быть заданы readкак , writeили admin, но не все разрешения поддерживают каждый из этих уровней. |

Разрешения

Каждое поддерживаемое разрешение задается с помощью имени в качестве параметра запроса с указанием требуемого уровня доступа. Допустимые уровни доступа: readи write``admin. Некоторые разрешения поддерживаются readтолько , некоторые поддерживают только writeнекоторые, и только несколько имеют admin. Используйте столько разрешений, сколько необходимо, в форме &contents=read&pull_requests=write&....

Вам не нужно включать и read``write разрешения в URL-адрес,write всегда включать readи admin всегда включать write.

Разрешения учетной записи

Разрешения учетной записи используются только в том случае, если текущий пользователь задан как владелец ресурса.

          `read`, `write` |

| codespaces_user_secrets | Секреты пользователя Codespaces | read, write | | copilot_messages | Копилот Чат | read | | copilot_editor_context | Контекст редактора Copilot | read | | copilot_requests | Запросы Copilot | write | | emails | Адреса электронной почты | read, write | | user_events | События | read | | followers | Followers | read, write | | gpg_keys | Ключи GPG | read, write | | gists | Gist | write | | keys | Ключи SSH Git | read, write | | interaction_limits | Ограничения взаимодействия | read, write | | knowledge_bases | Базы знаний | read, write | | user_models | Модели | read | | plan | Планирование | read | | private_repository_invitations | Приглашения к частному репозиторию | read | | profile | Профиль | write | | git_signing_ssh_public_keys | Ключи подписывания SSH | read, write | | starring | Добавление в избранное | read, write | | watching | Просмотр | read, write |

Разрешения репозитория

Разрешения репозитория работают как для владельцев ресурсов пользователей, так и для организаций.

          `read`, `write` |

| administration | Администрирование | read, write | | | | attestations | Аттестации | read, write | | | | security_events | Оповещения о проверке кода | read, write | | codespaces | Codespaces | read, write | | codespaces_lifecycle_admin | Администратор жизненного цикла codespaces | read, write | | codespaces_metadata | Метаданные codespaces | read | | codespaces_secrets | Секреты пространства кода | write | | statuses | Состояния фиксаций | read, write | | contents | Содержимое | read, write | | repository_custom_properties | Пользовательские свойства | read, write | | vulnerability_alerts | Оповещения Dependabot | read, write | | dependabot_secrets | Секреты Dependabot | read, write | | deployments | Развертывания | read, write | | discussions | Обсуждения | read, write | | environments | Среды | read, write | | issues | Проблемы | read, write | | merge_queues | Объединение очередей | read, write | | metadata | Метаданные | read | | pages | Страницы | read, write | | pull_requests | Запросы на включение внесенных изменений | read, write | | repository_advisories | Рекомендации по безопасности репозитория | read, write | | secret_scanning_alerts | Оповещения о проверке секретов | read, write | | secrets | Секреты | read, write | | actions_variables | Переменные | read, write | | repository_hooks | Веб-перехватчики | read, write | | workflows | Рабочие процессы | write |

Разрешения организации

Разрешения организации можно использовать только в том случае, если владелец ресурса является организацией.

          `read`, `write` |

| organization_user_blocking | Блокировка пользователей | read, write | | organization_campaigns | Кампании | read, write | | organization_custom_org_roles | Пользовательские роли организации | read, write | | organization_custom_properties | Настраиваемые свойства репозитория | read write admin | | organization_custom_roles | Пользовательские роли репозитория | read, write | | organization_events | События | read | | organization_copilot_seat_management | GitHub Copilot Бизнес | read, write | | issue_types | Типы проблем | read, write | | organization_knowledge_bases | Базы знаний | read, write | | members | Участники | read, write | | organization_models | Модели | read | | organization_network_configurations | Сетевые конфигурации | read, write | | organization_announcement_banners | Баннеры объявлений организации | read, write | | organization_codespaces | Пространства кода организации | read, write | | organization_codespaces_secrets | Секреты пространства кода организации | read, write | | organization_codespaces_settings | Параметры пространств кода организации | read, write | | organization_dependabot_secrets | Секреты зависимостей организации | read, write | | organization_code_scanning_dismissal_requests | Сканирование кода, выполняющее запросы на увольнение | read, write | | organization_private_registries | Частные реестры | read, write | | organization_plan | Планирование | read | | organization_projects | Проекты | read write admin | | organization_secrets | Секреты | read, write | | organization_self_hosted_runners | Локальные средства выполнения тестов | read, write | | team_discussions | Обсуждения в команде | read, write | | organization_actions_variables | Переменные | read, write | | organization_hooks | Веб-перехватчики | read, write |

Создание personal access token (classic)

1. В правом верхнем углу любой страницы на GitHubщелкните рисунок профиля, а затем выберите октикона "шестеренка" aria-hidden="true" aria-label="gear" %} Settings.

2. На левой боковой панели щелкните Параметры разработчика.

3. В левой боковой панели, под Personal access tokens, нажмите Tokens (classic).

4. Выберите "Создать новый маркер", а затем нажмите кнопку "Создать новый маркер" (классическая модель).

5. В поле "Примечание" присвойте маркеру описательное имя.

6. Чтобы предоставить маркер срок действия, выберите "Срок действия", а затем выберите параметр по умолчанию или нажмите кнопку "Пользовательский" , чтобы ввести дату.

7. Выберите области, которые вы хотите предоставить этому маркеру. Чтобы использовать маркер для доступа к репозиториям из командной строки, выберите repo. С помощью маркера без назначенных областей можно получить доступ только к общедоступной информации. Дополнительные сведения см. в разделе Области для приложений OAuth.

8. Щелкните Создать токен.

9. По необходимости, чтобы скопировать новый токен в буфер обмена, нажмите .

          ![Скриншот страницы «Personal access tokens». Рядом с размытым жетоном оранжевым цветом обведён значок двух перекрывающихся квадратов](/assets/images/help/settings/personal-access-tokens-ghes.png)
   

Удаление personal access token

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

1. В правом верхнем углу любой страницы на GitHubщелкните рисунок профиля, а затем выберите октикона "шестеренка" aria-hidden="true" aria-label="gear" %} Settings.

2. На левой боковой панели щелкните Параметры разработчика.

3. В левой боковой панели, под Personal access tokens, нажмите либо Fine-grained tokens , либо Tokens (classic), в зависимости от того personal access token , какой тип вы хотите удалить.

4. Справа от нужного personal access token удалить нажмите «Удалить».

Использование personal access token кнопки в командной строке

Когда у вас есть personal access token, вы можете ввести его вместо пароля при выполнении операций с Git через HTTPS.

Например, чтобы клонировать репозиторий в командной строке, введите следующую git clone команду. Затем вам будет предложено ввести имя пользователя и пароль. Если вас запросят пароль, введите «в» personal access token вместо пароля.

$ git clone https://HOSTNAME/USERNAME/REPO.git
Username: YOUR-USERNAME
Password: YOUR-PERSONAL-ACCESS-TOKEN

Хотя вы обязаны ввести своё имя пользователя вместе personal access tokenс , это имя пользователя не используется для аутентификации. Вместо этого используется personal access token для подтверждения вашей подлинности. Если вы не вводите имя пользователя, вы получите сообщение об ошибке о том, что учетные данные недопустимы.

          Personal access tokens можно использовать только для операций с HTTPS Git. Если в репозитории используется удаленный URL-адрес SSH, необходимо [переключить удаленный узел с SSH на HTTPS](/get-started/git-basics/managing-remote-repositories#switching-remote-urls-from-ssh-to-https).

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

Вместо ручного ввода personal access token для каждой операции HTTPS Git можно кэшировать personal access token с помощью Git-клиента. Git временно хранит учетные данные в памяти до истечения срока их действия. Вы также можете сохранить маркер в обычном текстовом файле, который Git может считывать перед каждым запросом. Дополнительные сведения см. в разделе Кэширование учетных данных GitHub в Git.

Дополнительные материалы

• Об аутентификации на GitHub
• Истечение срока действия и отзыв маркера