Руководство по регистрации приложений и OAuth для безопасной интеграции приложений

By Mirko Peters · 2026-05-04

Зарегистрируйте приложение с OAuth 2.0. Разберитесь в потоке авторизации по коду для безопасного доступа — ключевой части грант-типа authorization code в OAuth 2.0.

Automatically translated with AI from the original post. Read the English original

Давайте честно: правильно настроить аутентификацию и регистрацию приложений — это не только следовать хитрым протоколам. Важно, чтобы ваши пользователи, ваши данные и ваша организация оставались в безопасности. Это руководство помогает разобраться в регистрации приложений и OAuth 2.0, чтобы вы могли построить безопасную аутентификацию на основе стандартов с Microsoft Entra ID (ранее Azure AD) или с любым другим провайдером на ваш выбор.

Мы разберём шаги и концепции, которые вам понадобятся: от понимания того, зачем нужен OAuth, до практической реализации для веб-, мобильных и SaaS-приложений. По пути вы найдёте понятные определения, практические советы и дорожную карту, которая поможет держать интеграцию под контролем и избежать типичных ошибок, с которыми сталкиваются разработчики, впервые работающие с OAuth. Знакомитесь с темой впервые или тонко настраиваете сложную корпоративную инфраструктуру — вы в нужном месте, чтобы уверенно строить решения и понимать идентификаторы, необходимые вашему приложению.

Руководство по регистрации приложений и OAuth — определение

Регистрация приложения — это процесс создания и настройки идентичности приложения у поставщика идентификации (например, Azure AD, Google или Auth0), чтобы приложение могло безопасно запрашивать аутентификацию и авторизацию. Обычно это включает назначение client ID, client secret или сертификата, определение redirect URI, настройку разрешений и областей действия (scopes), а также указание допустимых типов грантов.

8 неожиданных фактов о руководстве по регистрации приложений и OAuth

• Client secrets могут утечь через логи: многие разработчики при отладке непреднамеренно записывают client ID и секреты в логи, из-за чего учётные данные регистрации приложения становятся уязвимыми, если политики логирования не ужесточены. Относитесь к идентификаторам всегда с осторожностью.
• Redirect URI строже, чем вы ожидаете: провайдеры OAuth часто требуют точного совпадения redirect URI (включая завершающий слеш и схему), поэтому незначительные различия могут сломать потоки, которые кажутся правильно настроенными в регистрации приложения.
• Публичным клиентам секреты не нужны, но защищать их всё равно нужно: нативные и одностраничные приложения считаются публичными клиентами без client secrets, однако им всё равно необходимо использовать PKCE и безопасные подходы к redirect, чтобы предотвратить перехват кода.
• Scopes по умолчанию не гарантируют минимальных привилегий: при регистрации приложений scopes по умолчанию или экраны согласия могут запрашивать широкие разрешения. Для соблюдения принципа минимальных привилегий необходимы явные ограничения scopes и инкрементальное согласие.
• Отзыв токенов поддерживается не везде: не все поставщики идентификации выполняют отзыв токенов или обеспечивают немедленный выход из всех сессий, поэтому регистрация приложения должна включать управление сессиями и политики refresh-токенов.
• Метаданные регистрации приложения — это поверхность атаки: публично доступные названия приложений, логотипы и redirect URI могут помочь злоумышленникам создать убедительный фишинг или атаки с открытым перенаправлением, если ими не управлять аккуратно.
• Автоматизированное развёртывание может неверно настроить разрешения: CI/CD-автоматизация, которая создаёт регистрации приложений, часто выдаёт избыточно широкие API-разрешения или не регистрирует нужные redirect URI, что приводит к тихим сбоям или утечкам безопасности.
• Интерфейс согласия влияет на решения по безопасности: пользователи и администраторы часто выдают широкое согласие, потому что диалоги согласия запутанны. Понятные и минимальные запросы согласия в регистрации приложения и руководстве по OAuth снижают избыточную выдачу доступа.

Понимание OAuth 2.0 и основ Entra ID

OAuth 2.0 — основа современных потоков аутентификации: он позволяет приложениям безопасно получать доступ к данным и ресурсам пользователя, не видя его пароля. Ниже — обзор процесса OAuth. По сути, OAuth 2.0 определяет, как пользователь («владелец ресурса»), приложение («клиент») и поставщик удостоверений («сервер авторизации») работают вместе, чтобы пользователи сохраняли контроль над своей информацией.

Но что делать, если нужно не только авторизовать доступ к данным, но и аутентифицировать самих пользователей? Здесь на помощь приходит OpenID Connect, который добавляет к OAuth 2.0 безопасную идентификацию и вход. С помощью OpenID Connect такие поставщики, как Microsoft Entra ID и Google, позволяют вашим приложениям проверять, кто перед ними, и в рамках одного унифицированного сценария запрашивать ограниченные разрешения на доступ к дополнительным ресурсам.

Если вы слышите такие термины, как «client ID», «authorization endpoint» или «access token», не пугайтесь. Все они сводятся к одному: кто с кем взаимодействует и что ему разрешено делать. Microsoft Entra ID использует эти протоколы, чтобы дать разработчикам стандартизированную основу — от бизнес-приложений для одного клиента до масштабных мультиклиентских SaaS-продуктов.

Понимание этих основ означает, что вы строите решение на проверенной базе. Выбор правильного потока OAuth для вашего сценария — например, code flow для веб-приложений или device flow для смart-телевизоров — обеспечивает безопасный и понятный вход, которому могут доверять пользователи и который оценит ваша команда по соблюдению требований.

Регистрация приложений и руководство по OAuth: типичные ошибки при работе с OAuth 2.0 и Entra ID

В этом руководстве по регистрации приложений и OAuth перечислены частые ошибки, которые команды допускают при реализации OAuth 2.0 с Microsoft Entra ID (Azure AD), и то, как они влияют на безопасность, функциональность и удобство для пользователей.

• Смешение понятий OAuth 2.0 и OpenID Connect (например, ожидание ID-токенов там, где выдаются только токены доступа).
• Неверное использование потоков OAuth: применение implicit flow в современных приложениях вместо Authorization Code с PKCE.

• Некорректно заданные redirect URI (неверная схема, завершающий слеш или использование localhost в производственной среде).
• Использование настроек публичного клиента для конфиденциальных приложений или наоборот, что приводит к ошибкам токенов или раскрывает секреты.
• Не заданы нужные разрешения API и области доступа (scopes) либо забыто предоставить согласие администратора там, где это требуется.

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

• Токены не проверяются должным образом (издатель, аудитория, подпись, nonce, exp).
• Небезопасное хранение токенов доступа или обновления (например, в локальном хранилище браузера без защиты).
• Доверие содержимому токенов без проверки областей доступа и ролей, возвращаемых Entra ID.

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

• Игнорирование ротации токенов обновления и политик их отзыва в Entra ID, что приводит к неожиданным выходам из системы.
• Использование токенов обновления в публичных клиентах без должной защиты (применяйте PKCE и подходящие сроки жизни токенов).

• Неправильная настройка мультиклиентских параметров для приложений, которые должны работать в разных клиентах.
• Использование неверных конечных точек (зависящих от клиента или общих) и возникновение проблем со входом или согласием.

• Не проверено поведение приложения при применении условного доступа, MFA или политик соответствия устройств.
• Предположение, что токены всегда будут выдаваться в одних и тех же условиях, неверно: политики могут блокировать их выдачу или требовать дополнительные шаги аутентификации.

• Использование устаревших потоков OAuth или шаблонов Azure AD v1 вместо рекомендаций платформы удостоверений Microsoft (v2).
• Применение примеров из сообщества без проверки того, реализованы ли в них безопасные практики (PKCE, безопасное хранение, корректная проверка).

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

Используйте это руководство по регистрации приложений и OAuth, чтобы проверить свою реализацию, следовать рекомендациям платформы удостоверений Microsoft и снизить риски для безопасности и эксплуатации при интеграции OAuth 2.0 с Entra ID.

Предварительные требования для регистрации приложения при настройке OAuth

Прежде чем переходить к экранам регистрации и вставлять название приложения в портал, проверьте несколько обязательных условий. Во-первых, вам нужен доступ к центру администрирования Microsoft Entra вашей организации или к соответствующей консоли того поставщика удостоверений, которым вы пользуетесь, без обходных путей. Без нужных разрешений вы упрётесь в стену ещё до того, как войдёте внутрь.

Далее решите, какое приложение вы создаёте и какие идентификаторы потребуются для его работы. Это веб-приложение, одностраничное приложение (SPA), мобильное приложение или, возможно, автоматизированный сервис? У каждого типа свои требования к аутентификации и авторизации. Если определиться с этим заранее, вы правильнее выберете параметры безопасности на следующих этапах.

Также важно определить, кто будет пользоваться приложением. Это будут только сотрудники вашей организации (один клиент) или приложению нужно обслуживать пользователей других компаний или широкую публику (несколько клиентов)? От этого зависят параметры регистрации, применяемые каталоги пользователей и поток согласия, который увидят ваши пользователи.

Наконец, соберите технические данные: допустимые URL для перенаправления при входе, поддерживаемые платформы (iOS, Android, Windows?) и разрешения (или «области»), которые приложению нужно запрашивать. Продуманные заранее детали экономят много времени при настройке и помогают избежать типичных проблем, например некорректных URI или несоответствия типов учётных записей на более поздних этапах.

Как зарегистрировать приложение в Microsoft Entra ID

Регистрация приложения в Microsoft Entra ID (ранее Azure AD) задаёт основу для всей работы с аутентификацией и доступом к API. Процесс начинается в центре администрирования Entra, где вы создаёте новую регистрацию приложения, которая присваивает вашему приложению уникальную идентичность («идентификатор клиента», client ID) в каталоге вашей организации.

Вы указываете название приложения, а затем выбираете, кто сможет им пользоваться: только ваша организация, несколько организаций или любая учётная запись Microsoft. Этот шаг очень важен, особенно для SaaS- и B2B-приложений, поскольку он определяет круг пользователей и то, как управляется согласие клиента.

После выбора аудитории настройте параметры платформы приложения. Для веб-приложений добавьте URI перенаправления; для мобильных и одностраничных приложений платформенные настройки обеспечат корректный вход. Портал Entra проведёт вас через добавление учётных данных, например клиентских секретов или сертификатов, которые приложение будет использовать для подтверждения своей личности.

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

Ключевые преимущества регистрации приложения в Microsoft Entra ID

• Централизованное управление удостоверениями: управляйте аутентификацией, авторизацией и учётными записями пользователей для своего приложения из одного клиента Entra ID.
• Безопасные потоки OAuth: используйте встроенную поддержку OAuth 2.0 и OpenID Connect для безопасного входа, выдачи токенов и делегированного доступа.
• Единый вход (SSO): обеспечьте бесшовный SSO в Microsoft 365, Azure и других интегрированных сервисах, чтобы улучшить пользовательский опыт и сократить количество запросов пароля.
• Детальное управление разрешениями: определение и управление гранулярными разрешениями API, сценариями согласия и доступом по принципу наименьших привилегий для делегированных и application-разрешений.
• Условный доступ и политики безопасности: применение MFA, политик соответствия устройств, геолокации и политик на основе рисков для защиты доступа к приложениям и конфиденциальным данным.
• Управление секретами и учетными данными приложений: безопасное хранение и ротация клиентских секретов, сертификатов и конфигурации для нескольких клиентов с практиками управления жизненным циклом, чтобы сохранять целостность использования приложений.
• Интеграция со службами платформы Microsoft: доступ к Microsoft Graph, API Azure, Teams и другим возможностям платформы с использованием стандартизированных токенов и моделей согласия.
• Поддержка гибридных и мультиплатформенных приложений: аутентификация пользователей в веб-, мобильных и настольных приложениях, а также в сценариях «сервис-сервис» с едиными протоколами идентификации; важно, чтобы каждое приложение использовало правильные идентификаторы.
• Мониторинг и аудит: использование журналов, отчетов о входах и аналитики безопасности для обнаружения аномалий, расследования инцидентов и поддержания соответствия требованиям.
• Масштабируемость и готовность к корпоративному использованию: использование глобальной инфраструктуры Entra ID, вариантов для нескольких клиентов и корпоративных функций для поддержки растущего числа пользователей и сложных организационных потребностей.
• Инструменты разработчика и документация: SDK, примеры кода и руководство по регистрации приложений и OAuth помогут ускорить внедрение и устранение типовых проблем.

Настройка URI перенаправления и параметров платформы для приложений Entra ID

Задать правильные URI перенаправления при регистрации приложения кажется простым шагом, но от него во многом зависит безопасность. URI перенаправления указывают Entra ID, куда отправить пользователя (вместе с его токенами) после успешной попытки входа. При их настройке Entra применяет строгие правила: никаких шаблонных доменов с подстановочными знаками, никаких опасных схем URI и никаких «хвостов», которыми могут воспользоваться злоумышленники.

Если вы создаете одностраничное приложение (SPA), обычно используется URL HTTPS, указывающий на домен приложения, что обеспечивает безопасный обмен данными. Нативным приложениям нужны схемы URI, привязанные к имени пакета или бандла приложения; это не позволяет произвольным приложениям на том же устройстве перехватывать токены. Веб-приложения обычно используют конечные точки обратного вызова для входа, и каждая из них должна быть явно указана.

Ошибки в настройке приводят к классической ошибке «redirect URI mismatch» и, что еще хуже, открывают злоумышленникам возможность перехватить токены. Потраченное время на то, чтобы спланировать каждую платформу, на которой будет работать приложение, и соответствующие URI перенаправления, помогает обеспечить бесперебойную аутентификацию и спокойствие.

Не забывайте обновлять регистрацию приложения при изменении клиентских URL, добавлении платформ или расширении сред (например, тестовой и production). Защищенные и аккуратно поддерживаемые URI — первый шаг к тому, чтобы поток токенов оставался надежным.

Основы потоков OAuth и управления токенами

OAuth 2.0 построен на наборе потоков авторизации, которые решают разные задачи: вход в веб-приложения, мобильные входы, вызовы «сервер-сервер» или работу приложений без участия пользователя. Самым распространенным и безопасным из них является поток с кодом авторизации, который позволяет не передавать чувствительные токены в браузеры и мобильные приложения и ставит безопасность на первое место.

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

Управление токенами — это не только контроль сроков действия; это защита токенов на каждом этапе. Сюда входят использование безопасного обмена данными (например, HTTPS), недопущение раскрытия секретов в клиентском коде и применение принципа наименьших привилегий при запросе областей доступа (scopes).

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

Реализация потока авторизации OAuth с кодом авторизации

1. Запуск авторизации: приложение перенаправляет пользователя на конечную точку авторизации Entra ID, передавая такие параметры, как идентификатор клиента, запрошенные области доступа и уникальный случайный параметр state для защиты от CSRF.
2. Предоставление разрешения: пользователь просматривает экран согласия, на котором четко указано, какие разрешения нужны приложению, и подтверждает доступ.
3. Получение кода авторизации: после согласия Entra ID перенаправляет на указанный вами redirect URI и передаёт временный код авторизации вместе со значением state, которое вы задали изначально.
4. Обмен кода на токены: ваш бэкенд безопасно отправляет код вместе с учётными данными клиента (а также PKCE code verifier, если он используется) на токен-эндпоинт Entra. После проверки вы получаете токен доступа и, как правило, токен обновления.
5. Использование токенов для доступа к API: теперь ваше приложение прикрепляет токен доступа к каждому запросу к API, подтверждая авторизацию от имени пользователя. Токены доступа действуют ограниченное время, что снижает риски, а токены обновления позволяют получать новые токены доступа для непрерывных сеансов.

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

Лучшие практики управления сроком действия токенов доступа и обновления

1. Надёжно храните токены: используйте защищённые хранилища, предоставляемые операционной системой, например Keychain на iOS, Keystore на Android, или зашифрованные хранилища секретов на сервере. Никогда не записывайте токены жёстко в двоичные файлы приложения и не выводите их в журналы.
2. Учитывайте сроки жизни токенов: отслеживайте значение срока действия (claim exp) в каждом токене и обновляйте его заранее, до истечения срока, чтобы избежать неудачных запросов к API и плохого пользовательского опыта.
3. Поддерживайте ротацию токенов: всегда используйте самый новый токен обновления при каждом запросе и быстро отбрасывайте повторно использованные или устаревшие токены. Это ограничивает последствия, если токен будет скомпрометирован.
4. Ограничивайте разрешения для каждого токена: запрашивайте только те области (scopes), которые действительно нужны, и предпочитайте короткоживущие токены доступа. Это существенно уменьшает ущерб, если токен когда-либо утечёт или будет украден.

Защита реализаций OAuth в различных контекстах

Правильно настроить интеграцию OAuth — это больше, чем выполнить список шагов: нужно строить многоуровневую защиту, соответствующую архитектуре приложения и сценариям использования. Работает ли ваше приложение в браузере, на телефоне или полностью в облаке, для каждого контекста нужны подходящие стратегии аутентификации.

Такие технологии, как PKCE (Proof Key for Code Exchange), защищают поток с кодом для публичных клиентов и не дают злоумышленникам перехватить код и обменять его на токены. С другой стороны, для приложений, работающих в защищённой среде, наилучшими инструментами для подтверждения идентичности и управления доверием становятся секреты клиента и сертификаты.

Аккуратное хранение токенов и внимательный контроль уровней привилегий помогают избежать случайных утечек и ограничить возможный ущерб, если что-то пойдёт не так. Выбирая правильные инструменты безопасности — PKCE, секреты, сертификаты и корректно заданные области доступа, — вы существенно сокращаете поверхность атаки и повышаете шансы на стабильную и соответствующую требованиям работу.

Ниже описаны проверенные стратегии, которые защищают от типичных угроз и помогают настроить OAuth для надёжной защиты приложений любых типов и сред.

Как PKCE защищает авторизацию OAuth в публичных клиентах

PKCE (Proof Key for Code Exchange) особенно важен при использовании OAuth в мобильных приложениях и приложениях на основе браузера — публичных клиентах, где невозможно хранить секрет. При запуске потока авторизации с кодом приложение генерирует случайный «code verifier» и хешированный «code challenge». Эти значения передаются вместе с пользователем и в финальном запросе токена. Даже если злоумышленник перехватит код авторизации, он не сможет обменять его на токен без этого секретного verifier, что делает атаки перехвата кода в Microsoft Entra ID и аналогичных платформах практически невозможными.

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

• Секреты клиента: используются конфиденциальными приложениями, например доверенными бэкенд-сервисами, чтобы подтверждать свою идентичность на токен-эндпоинте. Храните секреты в защищённых хранилищах, регулярно меняйте их и никогда не включайте в клиентский код приложения.
• Сертификаты: для более высокой степени доверия используйте сертификаты X.509 вместо обычных секретов, чтобы повысить безопасность идентификаторов вашего приложения. Сертификаты обеспечивают более надёжную проверку с помощью пары открытого и закрытого ключей и идеально подходят для регулируемых отраслей или приложений с жёсткими требованиями соответствия.
• Федеративные учётные данные: для сценариев «используйте собственную идентичность» применяйте федеративные учётные данные, например федеративную идентичность Microsoft Entra или внешних поставщиков. Это позволяет проходить аутентификацию без прямой работы с секретами и снижает нагрузку на управление.
• Обработка в конвейерах: в CI/CD-процессах внедряйте и при необходимости меняйте секреты и сертификаты, никогда не записывая их жёстко в систему управления исходным кодом. Автоматические оповещения об истечении срока действия добавляют ещё один уровень надёжности.

Защита токенов и снижение рисков избыточных привилегий

• Храните токены только в защищённых хранилищах (системные хранилища ОС, зашифрованные серверные среды), но никогда в хранилищах, доступных пользователю.
• Всегда передавайте токены по HTTPS или другим защищённым каналам: при обычном HTTP токены можно перехватить.
• Запрашивайте минимальные разрешения («scopes») для каждого токена: никогда не запрашивайте больше, чем нужно вашему приложению.
• Регулярно проверяйте использование токенов и назначения привилегий, чтобы своевременно выявлять незаметное расширение разрешений.

Лучшие практики OAuth для мобильных и нативных приложений

У мобильных и нативных приложений сегодня свои сложности: устройства теряются, приложения используют общее хранилище, а пользователи ожидают быстрого и почти незаметного входа. Поэтому соблюдение рекомендаций OAuth на iOS, Android и настольных системах, с использованием встроенных SDK и проверенных механизмов хранения, действительно важно.

Подходящий SDK (например, MSAL для Microsoft Entra ID) берёт на себя многое: управление токенами, логику обновления и интеграцию с защищённым хранилищем на уровне ОС. Для чувствительных токенов эти SDK по умолчанию выбирают самое безопасное место хранения, учитывая особенности конкретного устройства или ОС.

Не забывайте и о удобстве: универсальные ссылки, глубокие ссылки и потоки через системный браузер помогают пользователям завершить вход без путаницы и риска фишинга. При правильной настройке приложение перенаправляет пользователя в защищённое доверенное системное веб-окно, а после завершения входа безопасно возвращает его в приложение: без всплывающих окон и утечек токенов.

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

Универсальные ссылки и нативная аутентификация первого лица

Универсальные ссылки (на iOS) и схемы приложений (на Android) делают аутентификацию пользователей значительно безопаснее. Используя ссылки, подтверждённые операционной системой и привязанные к идентичности вашего приложения, вы не даёте сторонним приложениям перехватывать перенаправления при входе и получать чужие токены. Нативная аутентификация использует доверенные системные браузеры, поэтому входит именно настоящий пользователь, а фишинг, перехват токенов и случайные входы через не связанные между собой приложения исключаются. Вместе эти инструменты обеспечивают удобный и безопасный сценарий, который почти полностью защищён от типичных угроз мобильного OAuth.

Устранение ошибок OAuth и сложные сценарии

Интеграция OAuth редко проходит идеально с первой попытки: ошибки и нестандартные ситуации здесь обычное дело. Нередко проблемы возникают из-за несовпадения URI перенаправления, истёкших кодов или ошибочных клиентских секретов, которые могут полностью остановить процессы аутентификации и повлиять на работу приложений. Этот раздел поможет расшифровать ответы с ошибками, отследить неудачные обмены и устранить проблемы до того, как они попадут в службу поддержки.

Помимо базовых сценариев, некоторые задачи, такие как взаимодействие между серверами, вход на IoT-устройствах или необходимость более строгих гарантий протокола, требуют специализированных расширений OAuth или неинтерактивных потоков. Учётные записи служб, взаимный TLS и потоки с кодом устройства созданы именно для таких требований.

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

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

Расшифровка ответов с ошибками OAuth и сбоев обмена кодами

• Недопустимый URI перенаправления: возникает, когда адрес перенаправления не совпадает с зарегистрированным списком; перепроверьте введённые данные и регистр символов.
• Истёкший код авторизации: пользователи слишком долго проходят процедуру или коды используются повторно; всегда используйте код только один раз и сразу после получения.
• Несовпадение учётных данных клиента: передан неверный секрет или сертификат; проверьте учётные данные и при необходимости обновите их.
• Недопустимая область действия или ресурс: запрошенный API или scopes не разрешены либо указаны с опечаткой; проверьте конфигурацию и разрешения приложения.

Учётные записи служб, устройства с ограниченным вводом и расширения OAuth

• Учётные записи служб (поток учётных данных клиента): позволяют приложениям проходить аутентификацию без участия пользователя; отлично подходят для автоматизации и фоновых задач между серверами.
• Поток с кодом устройства: используется для смарт-телевизоров и IoT; предлагает пользователю войти на другом устройстве; подходит там, где браузер недоступен.
• Расширение взаимного TLS: использует сертификаты и для сервера, и для клиента, повышая безопасность чувствительных интеграций и гарантируя, что приложение использует надёжные методы аутентификации.
• Динамическая регистрация клиентов: автоматизирует подключение приложений в крупных SaaS- или мультиарендных системах, упрощая управление учётными данными в масштабе.

Руководство по регистрации приложений и OAuth в Entra ID

Плюсы

• Централизованное управление идентификацией: интеграция с Microsoft Entra ID обеспечивает единообразную идентификацию пользователей и приложений во всех сервисах.
• Надёжные средства безопасности: поддержка OAuth 2.0, OpenID Connect, условного доступа и детализированных разрешений (области и роли).
• Отраслевые стандартные протоколы: использование широко поддерживаемых стандартов OAuth/OIDC упрощает взаимодействие со сторонними инструментами и библиотеками.
• Подробная настройка приложений: позволяет задавать URI перенаправления, сертификаты и секреты, разрешения API и параметры брендинга.
• Гранулярная модель согласия: поддерживаются делегированные разрешения и разрешения приложений, а также потоки согласия администратора, которые ограничивают избыточные привилегии приложений.
• Корпоративные возможности: поддержка мультиарендных приложений, сотрудничества B2B и интеграции с Microsoft 365 и службами Azure.
• Мониторинг и аудит: встроенные журналы, входы в систему и журналы аудита для регистраций приложений и потоков OAuth помогают в соблюдении требований и устранении неполадок.
• Инструменты разработчика и SDK: обширный набор SDK платформы удостоверений Microsoft, документация и примеры быстрого старта упрощают внедрение.

Минусы

• Сложность для новичков: конфигурация и модели разрешений (URI перенаправления, URL-адреса ответа, неявный и код авторизации, области) могут сбивать с толку начинающих разработчиков.
• Крутая кривая обучения для функций безопасности: условный доступ, управляемые удостоверения и расширенные параметры токенов требуют глубоких знаний безопасности для безопасной настройки.
• Риск разрастания разрешений: неправильное согласие или широкие разрешения приложений могут привести к избыточным привилегиям, если их регулярно не проверять.
• Особенности управления токенами: обработка токенов обновления, сроков жизни токенов и их отзыва имеет особенности, зависящие от платформы, что может вызывать проблемы интеграции.
• Границы клиентов: поведение мультиарендных приложений и запросы согласия администратора усложняют эксплуатацию в сценариях между клиентами.
• Изменения интерфейса и терминологии: Microsoft периодически обновляет интерфейс и названия Entra (Azure AD → Entra ID), что может приводить к расхождениям в документации и путанице.
• Зависимость от экосистемы Microsoft: тесная связь с функциями Entra ID может затруднить переход к поставщикам удостоверений, отличным от Microsoft, без переработки.
• Риск неправильной настройки: некорректные параметры регистрации приложений (например, URI перенаправления, URL-адреса ответа, настройки неявного потока) могут создать уязвимости безопасности или нарушить процессы аутентификации.

Следующие шаги и ключевые ресурсы сообщества для успеха с OAuth

Итак, OAuth настроен и работает, но не сбавляйте темп: убедитесь, что приложение для получения токенов настроено правильно. Базовая настройка — только первый шаг. Если вы хотите, чтобы ваше приложение выделялось и защищало пользователей, пора изучить дополнительные возможности. Начните с продвинутых клиентских библиотек, поэкспериментируйте с Microsoft Graph и изучите новые функции удостоверений, которые сделают вашу интеграцию надёжнее и удобнее для всех участников.

И решать всё в одиночку необязательно. Документация по Microsoft Entra ID объёмная, как озеро Мичиган, и содержит актуальные руководства, примеры кода и технические спецификации, которые вам наверняка понадобятся. Сделайте привычкой проверять обновления, особенно с учётом того, что стандарты OAuth и облачной идентификации постоянно меняются.

Довольны регистрацией приложения? Отлично. Теперь посмотрите, как коллеги находят творческие решения. Загляните на форумы разработчиков, официальные форумы обсуждений и даже в репозитории GitHub с библиотеками аутентификации. Если вы упрётесь в стену, велика вероятность, что кто-то уже решил именно вашу проблему или, по крайней мере, громко пожаловался на неё, и кто-то ответил.

Если вы из тех, кто любит экспериментировать и учиться на практике, изучите доступные бесплатные пробные версии, тестовые клиенты и функции публичного предварительного просмотра. Они позволяют безопасно ломать и выяснять, что работает, прежде чем вносить изменения для реальных пользователей. И не забывайте: OAuth и безопасность — это коллективная работа, поэтому делитесь своими успехами и вопросами. Так экосистема остаётся открытой и крепнет, а всем становится понятнее, как работает OAuth.

Контрольный список регистрации приложений и OAuth — Entra ID

• Определите тип приложения и модель доступа: выберите между однорендным, мультиарендным или личными учётными записями Microsoft, а также определите тип: SPA, веб-приложение, мобильное, демон или служебное приложение.
• Регистрация приложения в Entra ID: создайте новую регистрацию приложения с понятным названием и поддерживаемыми типами учетных записей.
• Настройка URI перенаправления: добавьте правильные URI перенаправления и обратного вызова для каждой платформы (https, пользовательская схема, localhost для разработки).
• Настройка платформы приложения: включите параметры для одностраничных приложений (SPA), веб-приложений и мобильных и настольных приложений, а также при необходимости настройте неявный поток и другие потоки предоставления доступа.
• Создание и управление секретами клиента: создайте секреты клиента для конфиденциальных клиентов, зафиксируйте срок их действия и храните их в безопасном месте (Key Vault).
• Использование сертификатов для аутентификации: для конфиденциальных клиентов в рабочей среде загружайте сертификаты с открытым ключом вместо долгоживущих секретов.
• Настройка разрешений API: добавьте области и разрешения Microsoft Graph или собственных API, необходимые приложению.
• Предоставление согласия администратора там, где это требуется: запросите и зафиксируйте согласие администратора на делегированные разрешения, которые требуют согласия на уровне всего клиента.
• Определение и предоставление собственных областей (если вы создаете API): добавьте области в разделе «Предоставление API», задайте их имена, описания и отображаемые имена для согласия администратора.
• Настройка ролей приложения (при необходимости): определите роли приложения и делегированные роли для управления доступом на основе ролей и назначьте их пользователям, группам или клиентским приложениям.
• Настройка CORS для SPA, обращающихся к API: добавьте разрешенные источники в API или настройте политики CORS на шлюзе.
• Выбор потока OAuth 2.0: в зависимости от задачи выберите Authorization Code (с PKCE для публичных клиентов), Client Credentials для фоновых служб (daemon) или Device Code.
• Использование PKCE для публичных клиентов: требуйте Proof Key for Code Exchange для SPA и нативных приложений, чтобы предотвратить перехват кода авторизации.
• Корректная проверка токенов: проверяйте издателя, аудиторию, подпись, срок действия и обязательные утверждения (claims) с помощью библиотек идентификации Майкрософт или собственной логики проверки JWT.
• Использование библиотек проверки подлинности Майкрософт (MSAL): для получения, кэширования и обновления токенов, а также для безопасной работы на разных платформах предпочитайте MSAL.
• Настройка условного доступа и MFA (при необходимости): примените политики к регистрации приложения или к потокам входа пользователей, чтобы обеспечить соблюдение мер безопасности.
• Мониторинг входов и журналов аудита: включите логирование и проверяйте события входа, согласия и административные операции в журналах Entra ID.
• Принцип наименьших привилегий: запрашивайте только необходимые разрешения и используйте пошаговое согласие, чтобы минимизировать риски.
• Регулярная ротация секретов и сертификатов: настройте автоматическую ротацию и оповещения об истекающих учетных данных.
• Защита клиентского кода и хранилища: не храните секреты в клиентских приложениях, используйте безопасное хранилище и рекомендации платформы.
• Тестирование входа и потоков токенов в средах разработки и тестирования: проверьте потоки аутентификации, сроки жизни токенов, логику обновления, обработку ошибок и пользовательский опыт при согласии.
• Подготовка документации для пользователей и администраторов: включите шаги согласия, необходимые разрешения и рекомендации по устранению неполадок.
• Периодический пересмотр и обновление регистраций приложений: проверяйте разрешения, роли, секреты и регистрации на предмет устаревших или неиспользуемых приложений.
• Защита сети и API: рассмотрите API Management, WAF, ограничение частоты запросов и сервисные конечные точки для защиты серверных API.

Использование токена доступа Azure и OAuth для аутентификации

Что такое руководство по регистрации приложений и OAuth и почему оно важно?

Руководство по регистрации приложений и OAuth объясняет, как зарегистрировать клиентское приложение в поставщике удостоверений (например, в Azure) и реализовать потоки авторизации OAuth 2.0, чтобы ваше приложение могло безопасно запрашивать доступ к защищенным ресурсам. Это важно независимо от того, создаете ли вы веб-приложения, одностраничные приложения, настольные приложения или серверные части веб-серверов, поскольку для получения токена доступа и, при необходимости, токена ID приложению нужны идентификатор приложения (app id или application id), client id и client secret (для конфиденциальных клиентов).

Как зарегистрировать приложение в Azure и получить идентификатор приложения (application id и app id)?

Чтобы зарегистрировать приложение в Azure, перейдите на портал Azure, создайте новую регистрацию приложения, укажите имя и URI перенаправления, а также запишите client id (application id), который отображается в обзоре приложения. Если ваше приложение является конфиденциальным клиентом (веб-сервер или традиционное веб-приложение), создайте секрет клиента для использования вместе с client id и client secret. Зарегистрированное приложение используется при авторизации и для запроса токенов доступа от служб Майкрософт.

Какой поток авторизации OAuth 2.0 следует использовать для одностраничных приложений (SPA)?

Одностраничным приложениям (SPA) следует использовать поток с кодом авторизации и PKCE (Proof Key for Code Exchange), а не неявный поток (implicit flow), чтобы получение токенов было защищённым. Поток с кодом и PKCE позволяет приложению безопасно обменять код на токен доступа из клиента, работающего в браузере. Так одностраничные приложения могут использовать OAuth, не раскрывая секреты клиента в браузере.

Как работает запрос на авторизацию и какие параметры обязательны?

Запрос на авторизацию отправляется на конечную точку авторизации поставщика удостоверений и обычно включает client_id (идентификатор приложения), response_type (например, code), redirect_uri, scope и state. Для одностраничных приложений, использующих поток с кодом и PKCE, также передаются code_challenge и code_challenge_method. Пользователь проходит аутентификацию и даёт согласие (согласие OAuth), после чего сервер авторизации возвращает код на redirect URI, и приложение может обменять этот код на токен доступа.

Как реализовать обмен кода на токен доступа?

Получив код авторизации, клиентское приложение отправляет запрос на конечную точку токенов. В запросе передаются код, client_id (а для конфиденциальных клиентов также client_secret), redirect_uri и grant_type=authorization_code. При использовании PKCE добавляется code_verifier. В ответ конечная точка возвращает токен доступа, идентификационный токен (если он запрошен) и, возможно, токен обновления, с помощью которого можно получить новый токен доступа после истечения срока действия текущего.

Как получить токен доступа и использовать его для вызова API?

Чтобы получить токен доступа, выполните выбранный поток авторизации OAuth 2.0 и обратитесь к конечной точке токенов. Получив токен доступа, передавайте его в заголовке Authorization со схемой Bearer при вызове сервисов Microsoft или других API (например, Google Calendar или собственных API). Проверяйте токены на веб-сервере или на стороне ресурса, чтобы убедиться, что запросы приложения авторизованы.

Что делать, когда срок действия токена доступа истекает, и как получить новый токен обновления?

Когда срок действия токена доступа истекает, используйте токен обновления (если он был выдан), чтобы запросить токен доступа у конечной точки токенов с параметром grant_type=refresh_token. Некоторые потоки или провайдеры выдают новый токен обновления при обновлении, другие могут повторно использовать тот же токен. Если токен обновления недоступен (публичные клиенты или короткоживущие потоки), перенаправьте пользователя обратно в приложение для выполнения нового запроса на авторизацию.

Нужны ли отдельные регистрации приложений для веб-приложений и мобильных или настольных приложений?

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

В чём разница между регистрацией клиентского приложения и приложением в клиенте?

Регистрация клиентского приложения — это конкретная запись регистрации в поставщике удостоверений (приложение Azure), которая хранит такие параметры, как URI перенаправления и секреты. Приложение в клиенте означает, что регистрация находится в конкретном клиенте Azure AD и может получать роли и разрешения внутри этого клиента. Одна регистрация приложения может быть многоклиентской или одноклиентской в зависимости от ваших задач.

Как запросить доступ к сервисам Microsoft и какие разрешения для этого нужны?

Запросите доступ, указав в запросе авторизации области (scopes), которые нужны вашему приложению. Для сервисов Microsoft настройте разрешения API в регистрации приложения Azure, затем предложите пользователям дать согласие (согласие OAuth) или попросите администратора предоставить согласие для всего клиента. Приложение запрашивает области вроде User.Read или собственные области API в рамках запросов приложения и использует токен доступа для вызова сервисов.

Как защитить секреты клиента и не допустить утечки учётных данных в одностраничных приложениях?

Одностраничные приложения не должны хранить секреты клиента, поскольку код, выполняемый в браузере, можно изучить. Используйте поток с кодом авторизации и PKCE, чтобы приложение могло безопасно получить токен доступа без секрета клиента. Для конфиденциальных приложений (веб-серверов) храните идентификатор клиента и секрет клиента на стороне сервера, где они недоступны пользователям.

Какова роль URI перенаправления и почему он должен совпадать с регистрацией приложения?

Redirect URI — это адрес, на который поставщик удостоверений отправляет ответ авторизации (код или токен). Он должен совпадать с redirect URI, зарегистрированным в регистрации приложения, чтобы предотвратить перехват ответа авторизации. Используйте точное совпадение или разрешённые шаблоны, определённые поставщиком; при несоответствии обмен токена завершится ошибкой.

Как заставить пользователей пройти аутентификацию и получить id token наряду с access token?

Чтобы получить id token, запросите область openid и укажите response_type, который инициирует выдачу id token (поток авторизации с кодом и openid). Id token содержит утверждения об идентичности аутентифицированного пользователя. Используйте id token для входа пользователя в клиентское приложение, а access token — для вызова нижестоящих API.

Какие конкретные потоки авторизации применяются к традиционным веб-приложениям и одностраничным приложениям?

Традиционные веб-приложения (серверные) обычно используют поток авторизации с учётными данными клиента (client id и client secret) и обменивают код на веб-сервере. Одностраничные приложения (SPA) используют поток авторизации с кодом и PKCE без client secret. Классические настольные приложения также используют PKCE. Выбирайте поток в зависимости от типа приложения и того, где секреты можно надёжно хранить.

Можно ли использовать одну регистрацию приложения для нескольких клиентских приложений или лучше создать по одной регистрации на каждое приложение?

Одну регистрацию приложения можно использовать для нескольких клиентских приложений, если у них одинаковая конфигурация и redirect URI. Однако лучшие практики, как правило, рекомендуют отдельные регистрации для разных приложений, чтобы изолировать разрешения, redirect URI и управление жизненным циклом. Учитывайте, может ли приложению понадобиться другой набор областей разрешений или иное поведение согласия администратора.

Как проверять токены на веб-сервере или в API?

Веб-сервер или API должен проверять подпись, издателя (issuer), аудиторию (app id или application id) и срок действия access token или id token. Используйте документ обнаружения (discovery document) поставщика, чтобы получить ключи подписи, и применяйте рекомендованные библиотеки валидации для вашей платформы. Проверка гарантирует, что принимаются только запросы от аутентифицированных и авторизованных приложений.

Какова процедура запроса access token для серверной службы с использованием учётных данных клиента?

Для сценариев «сервер-сервер» зарегистрируйте приложение Azure, предоставьте ему разрешения уровня приложения, затем используйте поток учётных данных клиента: выполните POST-запрос к конечной точке токенов с grant_type=client_credentials, client_id, client_secret и scope/resource. Конечная точка вернёт access token, который серверная служба может использовать для вызова сервисов Microsoft или защищённых API.

Как обрабатывать согласие OAuth и согласие администратора для многоклиентских приложений?

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

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

Убедитесь, что приложение зарегистрировано на портале Microsoft, redirect URI совпадает, client id и secret верны, области разрешений допустимы, а тип потока и параметры PKCE (если используются) корректны. Проверьте сообщения об ошибках, возвращаемые конечными точками авторизации или токенов, и изучите журналы на клиенте и на сервере. Stack Overflow и документация поставщика могут помочь с конкретными кодами ошибок.

Как интегрировать сторонние API, например Google Calendar, с моим зарегистрированным приложением?

Для интеграции Google Calendar или других сторонних API реализуйте потоки авторизации OAuth 2.0, которые требуются этими поставщиками. Ваше приложение должно запрашивать правильные области для стороннего API и управлять отдельным жизненным циклом токенов. Возможно, потребуется отдельная регистрация клиентского приложения у каждого поставщика и согласование получения access token для каждого сервиса.

Когда следует использовать поток device code или другие специальные потоки для отдельных устройств?

Используйте поток device code для устройств с ограниченным вводом, где браузер недоступен. Этот поток позволяет пользователю открыть URL подтверждения на другом устройстве и пройти аутентификацию. Это один из специальных потоков авторизации, поддерживаемых наряду с потоком кода авторизации, учётных данных клиента и потоками обновления токена, чтобы учитывать различные форм-факторы приложений.