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

О personal access tokens

Personal access tokens — это альтернатива использованию паролей для проверки подлинности на GitHub при использовании API GitHub или командной строки.

Personal access tokens предназначены для доступа к ресурсам GitHub от имени себя. Чтобы получить доступ к ресурсам от имени организации или для длительных интеграции, следует использовать GitHub App. Дополнительные сведения см. в разделе О создании приложений GitHub.

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

Типы данных personal access tokens

GitHub в настоящее время поддерживает два типа данных personal access tokens: fine-grained personal access tokens и personal access tokens (classic). GitHub рекомендует использовать fine-grained personal access tokens вместо personal access tokens (classic) по возможности.

Оба данных fine-grained personal access tokens и 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 token для вашего сценария, вы сможете воспользоваться следующими улучшениями:

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

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

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

Основные пробелы в 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,которые управляют учетной записью Enterprise.
• С помощью 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), помните, что он предоставит доступ ко всем репозиториям в организациях, к которым у вас есть доступ, а также ко всем личным репозиториям в личная учетная запись.

В качестве меры предосторожности GitHub автоматически удаляет personal access token, которые не использовались в течение года. Чтобы обеспечить дополнительную безопасность, настоятельно рекомендуется добавить срок действия в personal access tokens.

Обеспечение безопасности данных personal access tokens

Personal access tokens похожи на пароли, и они используют одинаковые риски безопасности. Прежде чем создавать новые данные personal access token, рассмотрите возможность использования более безопасного метода проверки подлинности.

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

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

При использовании personal access token в скрипте можно хранить маркер в виде секрета и запускать скрипт с помощью GitHub Actions. Дополнительные сведения см. в разделе Использование секретов в GitHub Actions. Вы также можете сохранить маркер в виде секрета Codespaces и запустить скрипт в Codespaces. Дополнительные сведения см. в разделе Управление секретами, специфичными для ваших аккаунтов, для GitHub Codespaces.

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

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

1.        [Проверьте адрес](/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-email-preferences/verifying-your-email-address) электронной почты, если он еще не проверен. для повторного использования данных.user-settings.access_settings %} 1. На левой боковой панели щелкните **<svg version="1.1" width="16" height="16" viewBox="0 0 16 16" class="octicon octicon-code" aria-label="code" role="img"><path d="m11.28 3.22 4.25 4.25a.75.75 0 0 1 0 1.06l-4.25 4.25a.749.749 0 0 1-1.275-.326.749.749 0 0 1 .215-.734L13.94 8l-3.72-3.72a.749.749 0 0 1 .326-1.275.749.749 0 0 1 .734.215Zm-6.56 0a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042L2.06 8l3.72 3.72a.749.749 0 0 1-.326 1.275.749.749 0 0 1-.734-.215L.47 8.53a.75.75 0 0 1 0-1.06Z"></path></svg> Параметры разработчика**.
   

2. На левой боковой панели в разделе Personal access tokens, щелкните маркеры с точной детализацией.

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

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

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

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

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

8. При необходимости, если владелец ресурса является организацией, требующей утверждения для fine-grained personal access tokens, под владельцем ресурса в поле введите обоснование запроса.

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

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

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

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

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

Если вы выбрали организацию в качестве владельца ресурса и организации требует утверждения для 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-адресов, которые создают маркеры, которые мы видим чаще всего:

•         [Чтение содержимого репозитория](https://github.com/settings/personal-access-tokens/new?name=Repo-reading+token&description=Just+contents:read&contents=read)
  

•         [Отправка доступа к репозиториям](https://github.com/settings/personal-access-tokens/new?name=Repo-writing+token&description=Just+contents:write&contents=write)
  

•         [GitHub Доступ к моделям](https://github.com/settings/personal-access-tokens/new?name=GitHub+Models+token&description=Used%20to%20call%20GitHub%20Models%20APIs%20to%20easily%20run%20LLMs%3A%20https%3A%2F%2Fdocs.github.com%2Fgithub-models%2Fquickstart%23step-2-make-an-api-call&user_models=read)<!-- markdownlint-disable-line search-replace Custom rule -->
  

•         [Обновление кода и открытие PR](https://github.com/settings/personal-access-tokens/new?name=Core-loop+token&description=Write%20code%20and%20push%20it%20to%20main%21%20Includes%20permission%20to%20edit%20workflow%20files%20for%20Actions%20-%20remove%20%60workflows%3Awrite%60%20if%20you%20don%27t%20need%20to%20do%20that&contents=write&pull_requests=write&workflows=write)
  

•         [Управление Copilot лицензиями в организации](https://github.com/settings/personal-access-tokens/new?name=Core-loop+token&description=Enable%20or%20disable%20copilot%20access%20for%20users%20with%20the%20Seat%20Management%20APIs%3A%20https%3A%2F%2Fdocs.github.com%2Frest%2Fcopilot%2Fcopilot-user-management%0ABe%20sure%20to%20select%20an%20organization%20for%20your%20resource%20owner%20below%21&organization_copilot_seat_management=write)<!-- markdownlint-disable-line search-replace Custom rule -->
  

•         [Сделать Copilot запросы](https://github.com/settings/personal-access-tokens/new?name=Copilot+requests+token&description=Make%20Copilot%20API%20requests%20on%20behalf%20of%20the%20user%2C%20consuming%20premium%20requests%3A%20https%3A%2F%2Fdocs.github.com%2Fcopilot%2Fconcepts%2Fbilling%2Fcopilot-requests&user_copilot_requests=read)<!-- markdownlint-disable-line search-replace Custom rule -->
  

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

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

          `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.        [Проверьте адрес](/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-email-preferences/verifying-your-email-address) электронной почты, если он еще не проверен. для повторного использования данных.user-settings.access_settings %} 1. На левой боковой панели щелкните **<svg version="1.1" width="16" height="16" viewBox="0 0 16 16" class="octicon octicon-code" aria-label="code" role="img"><path d="m11.28 3.22 4.25 4.25a.75.75 0 0 1 0 1.06l-4.25 4.25a.749.749 0 0 1-1.275-.326.749.749 0 0 1 .215-.734L13.94 8l-3.72-3.72a.749.749 0 0 1 .326-1.275.749.749 0 0 1 .734.215Zm-6.56 0a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042L2.06 8l3.72 3.72a.749.749 0 0 1-.326 1.275.749.749 0 0 1-.734-.215L.47 8.53a.75.75 0 0 1 0-1.06Z"></path></svg> Параметры разработчика**.
   

2. На левой боковой панели в разделе Personal access tokens, щелкните Token (classic).

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

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

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

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

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

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

   

9. Чтобы использовать маркер для доступа к ресурсам, принадлежащим организации, использующей единый вход SAML, авторизации маркера. Дополнительные сведения см. в разделе Авторизация личного маркера доступа для использования с единым входом.

Удаление personal access token

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

1. В правом верхнем углу любой страницы на GitHubщелкните рисунок профиля, а затем выберите октикона "шестеренка" aria-hidden="true" aria-label="gear" %} Settings.
2. На левой боковой панели щелкните Параметры разработчика.
3. На левой боковой панели в разделе Personal access tokens, щелкните маркеры или маркеры**(классические)** в зависимости от типа personal access token вы хотите удалить.
4. Справа от personal access token необходимо удалить, нажмите кнопку "Удалить".

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

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

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

$ git clone https://github.com/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.

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

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

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

•         [AUTOTITLE](/authentication/keeping-your-account-and-data-secure/about-authentication-to-github)
  

•         [AUTOTITLE](/authentication/keeping-your-account-and-data-secure/token-expiration-and-revocation)