{"meta":{"title":"Рекомендации по созданию приложения OAuth","intro":"Следуйте этим рекомендациям, чтобы повысить безопасность и производительность вашего объекта OAuth app.","product":"Приложения","breadcrumbs":[{"href":"/ru/apps","title":"Приложения"},{"href":"/ru/apps/oauth-apps","title":"Приложения OAuth"},{"href":"/ru/apps/oauth-apps/building-oauth-apps","title":"Создание приложений OAuth"},{"href":"/ru/apps/oauth-apps/building-oauth-apps/best-practices-for-creating-an-oauth-app","title":"Рекомендации"}],"documentType":"article"},"body":"# Рекомендации по созданию приложения OAuth\n\nСледуйте этим рекомендациям, чтобы повысить безопасность и производительность вашего объекта OAuth app.\n\n## GitHub App Используйте вместо него\n\nЕсли это возможно, попробуйте использовать GitHub App вместо OAuth appнего. В общем случае предпочтительнее GitHub AppsOAuth apps.\nGitHub Apps используйте подробные разрешения, предоставьте пользователю больше контроля над тем, к каким репозиториям приложение может получить доступ, и использовать короткие маркеры. Эти свойства могут затвердить безопасность вашего приложения, ограничив ущерб, который можно сделать, если учетные данные вашего приложения просочились.\n\nOAuth appsАналогично, GitHub Apps можно использовать OAuth 2.0 и создавать тип маркера OAuth (называемый маркером доступа) и выполнять действия от имени пользователя. Однако также GitHub Apps может действовать независимо от пользователя.\n\nДополнительные сведения см. в GitHub Appsразделе [О создании приложений GitHub](/ru/apps/creating-github-apps/about-creating-github-apps/about-creating-github-apps).\n\nДополнительные сведения о переносе существующего OAuth app в a GitHub Appсм. в разделе [Миграция OAuth приложений на GitHub Apps](/ru/apps/creating-github-apps/about-creating-github-apps/migrating-oauth-apps-to-github-apps).\n\n## Использование минимальных областей\n\nНеобходимо OAuth app запросить только области, необходимые приложению для выполнения своих предполагаемых функций. Если какие-либо маркеры для приложения скомпрометируются, это приведет к ограничению объема ущерба, который может произойти. Дополнительные сведения см. в разделе [Авторизация приложений OAuth](/ru/apps/oauth-apps/building-oauth-apps/authorizing-oauth-apps).\n\n## Авторизовать тщательно и надежно\n\nПосле входа в систему разработчики приложений должны выполнить дополнительные действия, чтобы убедиться, что пользователь должен иметь доступ к данным в вашей системе. Для каждого входа требуются новые проверки членства, доступа и текущего состояния единого входа.\n\n### Использование устойчивого, уникального `id` для хранения пользователя\n\nКогда пользователь входит и выполняет действия в приложении, необходимо помнить, какой пользователь принял это действие, чтобы предоставить им доступ к тем же ресурсам при следующем входе.\n\nДля правильного хранения пользователей в базе данных всегда используйте `id` пользователя. Это значение никогда не изменится для пользователя или будет использоваться для указания другого пользователя, поэтому он гарантирует, что вы предоставляете доступ к пользователю, который вы намерены. Вы можете найти пользователя `id` с конечной `GET /user` точкой REST API. См [. раздел AUTOTITLE](/ru/rest/users/users#get-a-user).\n\nЕсли вы храните ссылки на репозитории, организации и предприятия, используйте их `id` , чтобы убедиться, что ссылки на них остаются точными.\n\n*Никогда не* используйте идентификаторы, которые могут изменяться с течением времени, включая дескриптор пользователей, слизки организации или адреса электронной почты.\n\n### Проверка доступа организации для каждой новой проверки подлинности\n\nПри входе пользователя следует отслеживать, для каких организаций разрешен маркер пользователя. Это может измениться с течением времени после входа, так как пользователи удаляются из организаций. Если организация использует единый вход SAML и пользователь не выполнил единый вход SAML, маркер доступа пользователя не будет иметь доступа к этой организации. Следует регулярно использовать конечную точку `GET /user/installations` REST API, чтобы проверить, к каким организациям имеется доступ маркера доступа пользователей. Если пользователь не авторизован для доступа к организации, следует запретить доступ к данным организации в собственном приложении, пока они не будут выполнять единый вход SAML или повторно присоединиться к организации. Дополнительные сведения см. в разделе [Конечные точки REST API для GitHub App установок](/ru/rest/apps/installations#list-app-installations-accessible-to-the-user-access-token).\n\n### Хранение пользовательских данных с помощью контекстов организации и предприятия\n\nПомимо отслеживания удостоверения пользователя с помощью `id` поля, необходимо сохранить данные для организации или предприятия, в которых работает каждый пользователь. Это поможет убедиться, что вы не утечете конфиденциальную информацию, если пользователь переключает роли.\n\nНапример:\n\n1. Пользователь находится в `Mona` организации, для которой требуется единый вход SAML и вход в приложение после выполнения единого входа. Теперь ваше приложение имеет доступ к тому, что пользователь делает внутри `Mona`.\n2. Пользователь извлекает кучу кода из репозитория `Mona` и сохраняет его в приложении для анализа.\n3. Позже пользователь переключает задания и удаляется из `Mona` организации.\n\nКогда пользователь обращается к приложению, он по-прежнему видит код и анализ из `Mona` организации в учетной записи пользователя?\n\nПоэтому важно отслеживать источник данных, сохраняемых приложением. В противном случае приложение является угрозой защиты данных для организаций, и они, скорее всего, запретят ваше приложение, если они не могут доверять, что ваше приложение правильно защищает свои данные.\n\n### Проверка доступа пользователя к приложению\n\nприложение OAuth может получить доступ к пользователям за пределами организации или предприятия. Если вы планируете использовать приложение только участниками вашей организации или предприятия, необходимо проверить состояние членства пользователя при входе пользователя в приложение.\n\nЧтобы найти список организаций, в которые входит пользователь, можно использовать конечную точку \"Список организаций для прошедших проверку подлинности пользователей\". Затем вы можете проверить этот список в списке утвержденных организаций для вашего приложения. Дополнительные сведения см. в разделе [Конечные точки REST API для организаций](/ru/rest/orgs/orgs#list-organizations-for-the-authenticated-user).\n\n## Защита учетных данных приложения\n\nС помощью секрета клиента и кода авторизации пользователя приложение может войти в систему пользователя и создать маркеры доступа. Эти маркеры можно использовать для выполнения запросов API от имени пользователя.\n\nЕсли это возможно, необходимо сохранить секрет клиента приложения и все созданные маркеры. Механизм хранения и его относительная безопасность зависят от архитектуры интеграции и платформы, на которой она работает. Как правило, следует использовать механизм хранения, предназначенный для хранения конфиденциальных данных на используемой платформе.\n\n### Секреты клиента\n\nСекреты клиентов необходимы для создания маркеров доступа для приложения, если приложение не использует поток устройства. Дополнительные сведения см. в разделе [Авторизация приложений OAuth](/ru/apps/oauth-apps/building-oauth-apps/authorizing-oauth-apps#device-flow).\n\nЕсли ваше приложение является конфиденциальным клиентом, то есть оно может безопасно хранить его в секрете, рассмотрите возможность хранения клиента в хранилище ключей, например, [Azure Key Vault](https://azure.microsoft.com/products/key-vault), или в виде зашифрованной переменной среды или секрета на вашем сервере.\n\nЕсли ваше приложение является общедоступным клиентом (собственное приложение, которое выполняется на устройстве пользователя, служебной программе CLI или веб-приложении с одной страницей), вы не можете защитить секрет клиента. Необходимо отправить секрет клиента в коде приложения и использовать PKCE для повышения безопасности потока проверки подлинности. Если вы планируете использовать доступ к собственным службам на основе маркеров, созданных приложением, следует будьте осторожны, так как общедоступные клиенты являются тривиально спуфингными. Любой пользователь может повторно использовать идентификатор клиента вашего приложения для входа.\n\n#### Не включать поток устройств без причины\n\nРекомендуется использовать код авторизации с PKCE через поток устройств, если вы обеспокоены использованием секрета клиента в общедоступном клиенте. Поток устройств не требует URI перенаправления вообще, что означает, что злоумышленник может использовать поток устройства для удаленного олицетворения приложения в рамках фишинговой атаки. По этой причине не включите поток устройств для приложения, если вы не используете приложение в ограниченной среде (CLIs, устройства Интернета вещей или системы без головы).\n\n### Токены доступа\n\nЕсли приложение является веб-сайтом или веб-приложением, необходимо зашифровать маркеры на серверной части и обеспечить безопасность в системах, которые могут получить доступ к маркерам. Рассмотрите возможность хранения маркеров обновления в отдельном месте от активных маркеров доступа.\n\nЕсли приложение является собственным клиентом, клиентским приложением или работает на пользовательском устройстве (а не на серверах), возможно, вы не сможете защитить маркеры, а также приложение, которое выполняется на серверах. Маркеры следует хранить с помощью механизма, рекомендуемого для платформы вашего приложения, и помните, что механизм хранения может быть не полностью безопасным.\n\n## Использование соответствующего типа токена\n\nOAuth apps может создавать маркеры доступа для выполнения запросов API, прошедших проверку подлинности. Ваше приложение никогда не должно использовать personal access token пароль для GitHub проверки подлинности.\n\n## Использование маркеров доступа с истекающим сроком действия\n\nЧтобы применить регулярное поворот маркера и уменьшить влияние скомпрометированного маркера, необходимо настроить OAuth app использование маркеров доступа, которые истекают. Когда приложение использует маркеры доступа, срок действия которого истекает, вы получите маркер обновления при создании маркера доступа. Срок действия маркера доступа истекает через восемь часов, а срок действия маркера обновления истекает через шесть месяцев. Маркер обновления можно использовать для создания нового маркера доступа и нового маркера обновления. Дополнительные сведения см. в разделе [Авторизация приложений OAuth](/ru/apps/oauth-apps/building-oauth-apps/authorizing-oauth-apps#expiring-access-tokens).\n\nЧтобы протестировать и постепенно развернуть поддержку маркеров истечения срока действия, вы можете принять маркеры истечения срока действия для входа, запросить `offline_access` область в дополнение к другим областям. Если ваше приложение поддерживает оба GitHub Enterprise Server и GitHub.com, будьте готовы `offline_access` к тому, чтобы область не влияла, так как GitHub Enterprise Server экземпляр пока не поддерживает маркеры истечения срока действия. Проверьте наличие поля в ответе маркера `expires_in` , чтобы понять, получено ли приложение маркера истечения срока действия.\n\n## Включение сопоставления подстановочных знаков для URL-адресов обратного вызова только при необходимости\n\n> \\[!WARNING]\n> Включение сопоставления с подстановочными знаками может предоставить приложению риски безопасности, так как он позволяет злоумышленнику отправлять коды авторизации в любой поддомен или подкаталог URL-адреса обратного вызова. Включить сопоставление с подстановочными знаками можно только в том случае, если это необходимо, и вы полностью уверены, что управляете всеми возможными поддоменами и путями URL-адреса обратного вызова. Дополнительные сведения см. в [рекомендации по обеспечению безопасности OAuth 2.0](https://www.rfc-editor.org/info/rfc9700/#section-4.1.1-11).\n\n## Создание плана по обработке нарушений безопасности\n\nУ вас должен быть план, чтобы вы могли своевременно обрабатывать любые нарушения безопасности.\n\nЕсли секрет клиента вашего приложения скомпрометирован, вам потребуется создать новый секрет, обновить приложение, чтобы использовать новый секрет и удалить старый секрет.\n\nЕсли маркеры доступа скомпрометируются, следует немедленно отозвать эти маркеры. Дополнительные сведения см. в разделе [Конечные точки REST API для авторизации OAuth](/ru/rest/apps/oauth-applications#delete-an-app-token).\n\n## Выполнение регулярных проверок уязвимостей\n\nСледует проводить регулярные проверки уязвимостей для приложения. Например, можно настроить сканирование кода и проверку секретов для репозитория, на котором размещен код приложения. Дополнительные сведения см. в разделе \\[AUTOTITLE и [Сканирование кода](/ru/code-security/concepts/code-scanning/code-scanning)]\\(/code-security/concepts/secret-security/secret-scanning).\n\n## Выбор подходящей среды\n\nЕсли приложение работает на сервере, убедитесь, что среда сервера безопасна и может обрабатывать объем ожидаемого трафика для приложения.\n\n## Безопасное использование служб\n\nЕсли приложение использует сторонние службы, они должны использоваться в безопасном режиме:\n\n* Все службы, используемые приложением, должны иметь уникальный вход и пароль.\n* Приложения не должны совместно использовать учетные записи служб, такие как электронная почта или службы баз данных, для управления службой SaaS.\n* Только сотрудники с административными обязанностями должны иметь доступ администратора к инфраструктуре, в которую размещается ваше приложение.\n\n## Добавление ведения журнала и мониторинга\n\nРассмотрите возможность добавления возможностей ведения журнала и мониторинга для приложения. Журнал безопасности может включать:\n\n* события аутентификации и авторизации;\n* изменения конфигурации службы;\n* операции чтения и записи объектов;\n* Изменения разрешений пользователей и групп\n* повышение прав роли до администратора;\n\nЖурналы должны использовать согласованную метку времени для каждого события и записывать пользователей, IP-адреса или имена узлов для всех зарегистрированных событий.\n\n## Включение удаления данных\n\nЕсли ваше приложение доступно другим пользователям, необходимо предоставить пользователям способ удаления своих данных. Чтобы удалить данные, пользователи не должны отправлять сообщения электронной почты или обращаться в службу поддержки.\n\n## Дополнительные материалы\n\n* [Лучшие практики безопасности приложений на GitHub Marketplace](/ru/apps/github-marketplace/creating-apps-for-github-marketplace/security-best-practices-for-apps-on-github-marketplace)\n* [Рекомендации по взаимодействию приложений с клиентами](/ru/apps/github-marketplace/creating-apps-for-github-marketplace/customer-experience-best-practices-for-apps)"}