На самом деле большинство людей считают, что учетные данные – это просто имя пользователя и пароль. Вводишь их, получаешь доступ и готово. Но когда вы – бизнес, работающий с клиентами, все становится намного сложнее. Что делать, если в приложении нужно зарегистрировать тысячи пользователей или дать им возможность войти через аккаунт Google, а не создавать очередной пароль? И как обеспечить безопасность данных клиентов, не смешивая их с каталогом сотрудников? Именно эту проблему призван решить Microsoft Intra External ID. Вот в чем суть. Он полностью заменяет Azure от B2C. К концу этого выпуска вы поймете, что такое External ID на самом деле, три основных способа его использования и почему это важно для любого клиентского приложения. Старый подход – отдельные изолированные системы идентификации. Представьте, что 20 лет назад вы создали приложение для клиентов. Тогда приходилось создавать систему входа с нуля, писать код для паролей, настраивать базу данных для их хранения, разрабатывать процесс восстановления пароля.

Для небольшого приложения с сотней пользователей это работало, но с ростом популярности все быстро усложнялось. Компаниям нужно было разрешить вход через Google или Facebook. Требовалась многофакторная аутентификация и способность обрабатывать миллионы аккаунтов без сбоев. Создавать все это самостоятельно было настоящим кошмаром. Первым ответом Microsoft стал Azure от B2C. Это был сервис идентификации клиентов, который в то время решал реальную проблему. Но тут начались сложности. Главной проблемой были так называемые пользовательские политики, которые писались на языке XML. Если вы хоть раз работали с XML-файлами на сотни строк, вы знаете, насколько это болезненно. Трудно настроить, трудно отладить. А если что-то ломалось, удачи в поисках причины. Вдобавок, Azure от B2C был отделен от основной платформы идентификации Microsoft. Поэтому, если у вас уже был Microsoft 365 или Azure для сотрудников, B2C ощущался как совершенно новый продукт, который нужно учить с нуля.

Как и следовало ожидать, IT-командам было сложно его поддерживать. Разработчики боялись с ним работать, а клиенты получали неудобный процесс регистрации, из-за которого уходили. В Microsoft поняли, что нужно что-то более простое и унифицированное. И именно это стало Microsoft Intra External ID. Что такое Microsoft Intra External ID на самом деле? Итак, что же такое Microsoft Intra External ID? Вот самое простое определение. Это облачный сервис идентификации для внешних пользователей, клиентов, партнеров и гостей, а не сотрудников. Посмотрите на это иначе. Представьте, что у вашей компании есть офисные здания. Это ваш арендатор для сотрудников. Это место, где работают ваши сотрудники, где стоят их столы и куда их пускают по пропускам. Intra ID управляет этим зданием. А теперь представьте, что вы открываете витрину для клиентов, отдельное пространство, свой вход, свои правила, своя безопасность.

Клиенты не забредут в комнату отдыха для персонала, а сотрудники не получат случайный доступ к аккаунтам клиентов. Это и есть External ID. Это часть семейства Microsoft Intra, но с другой спецификой. Система создана для CIM, управления идентификацией и доступом клиентов и охватывает весь жизненный цикл внешнего пользователя. Регистрация, вход, сброс пароля, управление профилем, многофакторная аутентификация, выдача токенов. Она работает со стандартными протоколами, такими как у AT2, 0, OpenID Connect и SAML. Поэтому к ней можно подключить почти любое приложение. Но вот в чем главное отличие от старого Azure ADB2C. External ID проще. Больше никаких пользовательских XML-политик. Вместо этого вы настраиваете потоки пользователей прямо в центре администрирования. Или используете настраиваемые расширения аутентификации, которые подключаются к вашей существующей логике бэкенда. Та же мощность.

Меньше головной боли. Три основных варианта использования.

External ID. Существует три основных сценария. Они охватывают почти любую ситуацию, когда вам нужно управлять тем, кто не является сотрудником. Начнем с самого распространенного. Идентификация клиентов или B2C. Представьте, что вы создаете приложение для заказа пиццы. Вам нужно, чтобы люди регистрировались, делали заказы и возвращались на следующей неделе. Вы хотите, чтобы они входили через свой аккаунт Google, а не создавали новый пароль. И вам нужно собирать их имена, номера телефонов и предпочтения по доставке. External ID справляется со всем этим. Вы получаете готовые потоки регистрации и входа. Вы настраиваете атрибуты, которые нужно собрать, имя, телефон, все, что вам нужно. Вы настраиваете социальный вход через Google, Facebook или Apple. И когда пользователь проходит аутентификацию, External ID выдает токен вашему приложению, чтобы оно знало, кто этот человек. Это замена Azure at B2C.

И именно с этого начинают большинство организаций. Еще один сценарий – это сотрудничество между компаниями или B2B. Это когда вам нужно предоставить партнерам или поставщикам доступ к вашим внутренним приложениям. Может быть, у вас есть сайт SharePoint, который должен видеть ваш внешний логистический партнер. Или инструмент управления проектами, который используют ваши дизайнеры-фрилансеры. В этом сценарии вы приглашаете их в качестве гостевых пользователей в ваш рабочий клиент. External ID управляет электронным письмом с приглашением, процессом активации, когда они принимают приглашения и политиками доступа, контролирующими, что они могут видеть. Это на самом деле существует уже много лет как B2B сотрудничество внутри Azure at. Но теперь это часть экосистемы External ID, поэтому вы управляете ею из того же места, что и идентификаторами ваших клиентов. Далее идет взаимодействие машина-машина или M2M.

Оно менее заметно для конечных пользователей, но не менее важно. Иногда вашему серверному приложению нужно взаимодействовать с другим API, платежным процессором, сервисом аналитики или внутренним микросервисом. Здесь не участвует человек, это просто вызов одного приложения другим. External ID использует поток предоставления учетных данных клиента у А2.0. Ваш сервис проходит аутентификацию с помощью идентификатора и секрета клиента, получая токен для вызова целевого API. Для этого требуется надстройка M2M Premium, что влечет за собой расходы, но если вам нужно защитить связь между API, это решение уже встроено. Эти три сценария охватывают практически все ситуации с внешними идентификаторами, с которыми вы столкнетесь. Но вам нужно принять важное решение, где именно будут находиться эти пользователи. Потому что External ID может работать в двух разных средах, в рабочем арендаторе или во внешнем арендаторе.

Давайте разберем эти два варианта. External ID может работать внутри вашего существующего рабочего арендатора или как полностью отдельный внешний арендатор. Это не одно и то же, и неправильный выбор может вызвать проблемы в будущем. Начнем с варианта рабочего арендатора. У вашей компании уже есть арендатор интро-ID для сотрудников. Это и есть ваш рабочий арендатор. Если вы включите функцию самостоятельной регистрации гостевых пользователей, они смогут зарегистрироваться и попасть в тот же каталог, где находятся ваши сотрудники. Их учетные записи окажутся рядом с учетной записью вашего генерального директора. Для простых B2B-сценариев, таких как приглашение нескольких партнеров на сайт SharePoint, совместное размещение в одном каталоге вполне допустимо. Это просто настроить, и вам не нужно управлять отдельным арендатором. Но есть один нюанс. Если вы создаете клиентское приложение с тысячами пользователей, вы вряд ли захотите, чтобы эти клиенты находились в одном каталоге с сотрудниками.

Это риск для безопасности. Сотрудник может случайно получить доступ к данным клиентов. Изменение конфигурации, предназначенное для сотрудников, может повлиять на доступ клиентов. А брендирование страниц входа для клиентов будет привязано к тому, что вы настроили для своей компании. Это не лучший вариант. Альтернатива – вариант с внешним арендатором. Вы создаете новый изолированный каталог специально для идентификаторов клиентов. Здесь нет сотрудников. Это полностью обособленное пространство. Помните аналогию с офисным зданием изначало. Рабочий арендатор – это ваш головной офис. Внешний арендатор – это отдельный магазин, который вы открываете для своих клиентов. У них свой вход, свои правила и своя система безопасности. Ничего не смешивается. Итак, каковы преимущества внешнего арендатора? Во-первых, вы получаете изолированное хранилище пользователей. Данные клиентов полностью отделены от данных сотрудников, что снижает риски и упрощает соблюдение требований.

Во-вторых, вы получаете отдельный брендинг. Вы можете настроить внешний вид страниц входа специально для своих клиентов, не затрагивая ничего в корпоративном клиенте. В-третьих, вы получаете собственные API-аутентификации для мобильных приложений, которые позволяют создавать полностью уникальные экраны входа в вашем приложении для iOS или Android. Никаких перенаправлений в браузер или неудобных веб-представлений. И в-четвертых, вы получаете ценообразование на основе MAU ежемесячно активных пользователей. Вы платите только за тех пользователей, которые действительно проходят аутентификацию в данном месяце, что естественным образом масштабируется с ростом вашей клиентской базы. Итак, когда и что выбирать? Все довольно просто. Если вы создаете B2C-приложение с тысячами клиентов, выбирайте внешний клиент – External Tenant. Это рекомендуемый подход, и именно для этого был разработан External ID.

Если вы просто приглашаете партнеров для доступа к внутренним ресурсам, подойдет вариант с рабочим клиентом. Главное – понять разницу до того, как вы начнете разработку, поскольку перенос из одного в другой впоследствии – задача не из легких. Безопасность, MFA и условный доступ. Теперь давайте поговорим о безопасности. Если вы собираетесь пускать клиентов в свое приложение, нужно убедиться, что туда не попадут посторонние. External ID включает в себя те же функции безопасности корпоративного уровня, что и IntraID предлагает для сотрудников. Это означает многофакторную аутентификацию, условный доступ и политики на основе рисков. Для MFA у вас сейчас есть два варианта. Одноразовый пароль по электронной почте предоставляется бесплатно. Система отправляет код на электронную почту пользователя, он вводит его, и все готово. Одноразовый SMS-пароль работает так же, но приходит на телефон, и здесь учитываются затраты оператора связи.

Стоит отметить, что поддержки Microsoft Authenticator пока нет. Это текущее ограничение, над которым Microsoft, вероятно, работает, но пока это только email или SMS. Условный доступ – это то, где начинаются самые интересные возможности. Вы можете задать правила, например, требовать MFA, если уровень риска входа средний или выше, или блокировать доступ из стран, с которыми вы не работаете. Система оценивает каждую попытку входа в режиме реального времени. Если кто-то пытается войти из места или с устройства, которые выглядят подозрительно, система может автоматически повысить требования безопасности, не заставляя вас самостоятельно внедрять эту логику. Но есть одна функция, которая действительно выделяется – пошаговая аутентификация. Вот как это работает. Представьте, что пользователь входит в ваше приложение только с паролем, чтобы просмотреть каталог продукции. Это подходит для действий с низким уровнем риска, но когда пользователь пытается просмотреть историю платежей или скачать счет, вам требуется дополнительная проверка.

Благодаря поэтапной аутентификации вы можете требовать MFA только для определенных разделов вашего приложения. Пользователю не будет приходить запрос до тех пор, пока он не попытается получить доступ к конфиденциальным данным. Все это обрабатывается external ID в фоновом режиме с использованием так называемого контекста аутентификации. Вы определяете, какие части вашего приложения требуют повышенной защиты, а система берет на себя остальное. Пользователь получает удобство при обычном просмотре, но конфиденциальные данные остаются под защитой. Брендинг и пользовательский опыт. Контроль над брендингом – одна из главных причин, по которой организации выбирают external ID вместо создания собственной системы входа. Вы получаете полный контроль над внешним видом страниц регистрации и входа. Можете загрузить логотип, задать светофона, добавить фавикон для вкладки браузера, а также настроить верхний и нижний колонн титулы со ссылками на политику конфиденциальности и условия использования.

Если вам нужно еще больше контроля, вы можете загрузить собственный CSS-файл для изменения шрифтов, цветов кнопок и макета. Это ваш бренд, ваши цвета. Вы все решаете сами. А вот здесь начинаются сложности. Брендинг настраивается глобально для арендатора, а не для каждого приложения отдельно. Поэтому, если у вас несколько приложений, например, клиентский портал и мобильное приложение, все они будут использовать одни и те же брендированные страницы. Вы не можете придать каждому приложению свой уникальный стиль. Старый Azure AdBad 2C позволял настраивать брендинг для каждого приложения, но External ID пока это не поддерживает. Еще одно ограничение — сообщение об ошибках на страницах входа нельзя настроить. Если пользователь введет несуществующий адрес электронной почты, он увидит что-то вроде «Мы не смогли найти учетную запись с этим адресом электронной почты». И вы не можете изменить этот текст.

Для некоторых организаций это нормально, но для других, особенно работающих в регулируемых отраслях или имеющих строгий фирменный стиль, это настоящая проблема. Для мобильных приложений есть вариант получше. External ID имеет API для нативной аутентификации в iOS и Android. Вместо перенаправления пользователей на страницу входа в браузере, вы можете создать полностью кастомные экраны входа прямо внутри приложения. Никаких перенаправлений в браузер или неуклюжих веб-представлений. Пользователь остается внутри вашего приложения, и вы контролируете каждый пиксель. Это гораздо более плавный опыт, и это одна из функций, которой никогда не было в Azure AdBad 2C. Миграция с Azure AdBad 2C. Если вы уже используете Azure AdBad 2C, вам наверняка интересно, что это значит для вас. Вот в чем суть. Microsoft продолжит поддерживать B2C как минимум до 2030 года. Так что ваши текущие арендаторы не перестанут работать завтра, но новых функций больше не будет.

Все инновации, ключи доступа, нативная аутентификация, защита от мошенничества доступны только в External ID. Вы находитесь на платформе, которая по сути заморожена. Microsoft выпустила официальные инструменты и руководство по миграции, предлагающие два пути в зависимости от масштаба. Для тенантов, содержащих менее 5 миллионов объектов каталога, пользователей, групп, пользовательских атрибутов, стандартная миграция довольно проста. Она работает как перенос между тенантами. Вы создаете новый тенант External ID, переносите пользователей и их учетные данные, а затем переключаете свои приложения. Microsoft предоставляет инструменты для массового экспорта и импорта пользователей, а также миграцию паролей по запросу, чтобы минимизировать перебой в работе. Для крупных тенантов с более чем 5 миллионами объектов существует режим высокомаштабируемой совместимости – HSC. В этом режиме Azure Red B2C и External ID работают параллельно в одном и том же тенанте.

Ваши существующие конечные точки B2C остаются активными, пока вы постепенно переносите приложение. Он предназначен для организаций, которые не могут перенести миллионы пользователей за одну ночь, но требует компромиссов. Отсутствие социальных провайдеров, ключей доступа, ограниченный условный доступ и некоторые другие функции просто недоступны. Рассматривайте это как промежуточную стратегию, а не постоянное решение. Теперь о важном изменении. Пользовательские политики исключены. Если вы создавали сложные процессы аутентификации на базе XML фреймворка Identity Experience в Azure Red B2C, они не будут работать в External ID. Вам придется перестроить эту логику с помощью потоков пользователей и пользовательских расширений аутентификации. Не существует волшебного инструмента, который преобразует ваш XML в новый формат. Вам просто придется выполнить эту работу самостоятельно. Итак, к чему все сводится?

Если вы начинаете с нуля сегодня, используйте External ID. Нет причин даже рассматривать B2C. Если у вас есть существующий тенант B2C, начните планировать миграцию прямо сейчас. У вас есть время до 2030 года, но если откладывать на последний момент, придется спешно выполнять сложную миграцию, параллельно поддерживая работу текущих приложений. Начните с малого. Выберите одно приложение, перенесите его, протестируйте, извлеките уроки, а затем сделайте остальное. Опыт разработчиков и автоматизация Microsoft уделила много внимания удобству External ID для разработчиков, и это огромный шаг вперед по сравнению со старыми политиками B2C. Помните те XML-файлы, которые растягивались на сотни строк и ломались из-за одной пропущенной скобки? Этого больше нет. Появилось расширение для Visual Studio Code под названием Microsoft Intra External ID. После аутентификации вы можете просматривать свой тенант, потоки пользователей, скачивать их в формате JSON и даже проверять брендинг, не выходя из редактора.

Вы видите, как выглядит страница входа еще до ее публикации. Кроме того, есть Microsoft Graph API. Почти каждым ресурсом External ID, потоками пользователей, регистрацией приложений, брендингом можно управлять программно. Это означает, что вы можете автоматизировать настройку тенанта в своих CI, CD-конвейерах с помощью PowerShell или REST-запросов. Создавайте новый клиент, настраивайте потоки пользователей, регистрируйте приложения и брендинг – все с помощью скрипта. Если вы управляете несколькими средами, это экономит массу времени. Пользовательские расширения аутентификации – вот где кроется настоящая сила. Вместо сложного XML вы расширяете потоки аутентификации простыми HTTP вызовами Azure Functions. Существует четыре события, к которым можно подключиться. Начало выдачи токена позволяет добавлять в токены пользовательские утверждения, такие как роли или уровень лояльности. Начало и отправка сбора атрибутов позволяют проверять или предзаполнять данные регистрации, обращаясь к вашему бэкенту.

А отправка одноразового пароля по почте позволяет настроить письма для верификации. Это та же гибкость, что была в B2C, но в модели, с которой справится любой разработчик. Есть ограничения, о которых стоит знать. Уведомлений Microsoft Graph пока нет, поэтому вы не можете автоматически запустить рабочий процесс при регистрации нового пользователя. Некоторые настройки все еще нужно выполнять вручную в центре, и встроенной странице редактирования профиля нет. Если нужно, чтобы пользователи обновляли информацию, создайте эту страницу в приложении и вызывайте Graph API самостоятельно. Но направление очевидно. Microsoft стремится к тому, чтобы External ID можно было полностью автоматизировать. Это упрощает управление при масштабировании. Теперь вы знаете, Microsoft Intra External ID – это современная замена Azure Red B2C, объединенная под брендом Intra. Три сценария – идентификация клиентов, сотрудничество с партнерами и взаимодействие между машинами – покрывают почти все внешние потребности.

Ключевое решение – использовать корпоративный клиент или создать отдельный внешний клиент. Для приложений, ориентированных на клиентов, отдельный клиент почти всегда лучше. Идентификация – это парадная дверь вашего приложения. Правильная, безопасная, брендированная и простая настройка напрямую влияет на доверие пользователей и рост бизнеса. Ваши домашние задания – перейдите на intro.microsoft.com. Создайте внешний клиент и попробуйте руководство по началу работы. Оно поможет вам настроить пример приложения за считанные минуты. Подписывайтесь, чтобы получать больше простых разборов платформы и идентификации Microsoft.