Типы удостоверений и учетных записей для приложений с одним и несколькими клиентами

В этой статье объясняется, как разработчик может выбрать, разрешено ли ваше приложение только пользователям из клиента Microsoft Entra, любого клиента Microsoft Entra или пользователей с личными учетными записями Майкрософт. Вы можете настроить приложение для одного клиента или мультитенантного во время регистрации приложений в Azure. Убедитесь, что принцип "Нулевое доверие" для доступа с минимальными привилегиями позволяет приложению запрашивать только необходимые разрешения.

Платформа удостоверений Майкрософт обеспечивает поддержку определенных типов удостоверений:

• Рабочие или учебные учетные записи, если сущность имеет учетную запись в идентификаторе Microsoft Entra
• Microsoft личная учетная запись (MSA) для всех, кто имеет учетную запись в Outlook.com, Hotmail, Live, Skype, Xbox и т. д.
• Внешние удостоверения в идентификаторе Microsoft Entra для партнеров (пользователи за пределами организации)
• Microsoft Entra Business to Customer (B2C), который позволяет создавать решение, которое позволит клиентам использовать другие поставщики удостоверений. Приложения, использующие Azure AD B2C или подписанные на Microsoft Dynamics 365 Fraud Protection с Помощью Azure Active Directory B2C , могут оценить потенциально мошеннические действия после попыток создания новых учетных записей или входа в экосистему клиента.

Необходимой частью регистрации приложений в идентификаторе Microsoft Entra является выбор поддерживаемых типов учетных записей. Хотя ИТ-специалисты в ролях администратора решают, кто может предоставить согласие на приложения в клиенте, вы, как разработчик, укажите, кто может использовать ваше приложение на основе типа учетной записи. Если клиент не позволяет зарегистрировать приложение в идентификаторе Microsoft Entra, администраторы предоставляют вам способ обмена данными с ними с помощью другого механизма.

При регистрации приложения вы выберете следующие поддерживаемые параметры типа учетной записи.

• Accounts in this organizational directory only (O365 only - Single tenant)
• Accounts in any organizational directory (Any Azure AD directory - Multitenant)
• Accounts in any organizational directory (Any Azure AD directory - Multitenant) and personal Microsoft accounts (e.g. Skype, Xbox)
• Personal Microsoft accounts only

Учетные записи только в этом каталоге организации — один клиент

При выборе учетных записей только в этом каталоге организации (только O365 — один клиент) можно разрешить только пользователям и гостям из клиента, где разработчик зарегистрировал свое приложение. Этот параметр является наиболее распространенным для бизнес-приложений.

Учетные записи только в любом каталоге организации — мультитенантные

При выборе учетных записей в любом каталоге организации (любой каталог Microsoft Entra — Multitenant) можно разрешить любому пользователю из любого каталога Microsoft Entra войти в мультитенантное приложение. Если вы хотите разрешить пользователям только определенные клиенты, вы отфильтруете этих пользователей в коде, проверка, что утверждение tid в id_token находится в списке разрешенных клиентов. Приложение может использовать конечную точку организации или общую конечную точку для входа пользователей в домашний клиент пользователя. Для поддержки входа гостевых пользователей в мультитенантное приложение вы будете использовать определенную конечную точку клиента для клиента, где пользователь является гостем для входа пользователя.

Учетные записи в любой учетной записи организации и личных учетных записях Майкрософт

При выборе учетных записей в любой учетной записи организации и личных учетных записях Майкрософт (любой каталог Microsoft Entra — Multitenant) и личных учетных записей Майкрософт (например, Skype, Xbox) пользователь может войти в приложение с собственным удостоверением из любого клиента Microsoft Entra или учетной записи потребителя. К этим приложениям применяются те же фильтры клиентов и использование конечных точек, что и для мультитенантных приложений, как описано выше.

Только личные учетные записи Майкрософт

При выборе только личных учетных записей Майкрософт вы разрешаете использовать приложение только пользователям с учетными записями потребителей.

Клиентские приложения

При создании решения в платформа удостоверений Майкрософт, которая обращается к клиентам, обычно не требуется использовать корпоративный каталог. Вместо этого вы хотите, чтобы клиенты были в отдельном каталоге, чтобы они не могли получить доступ к каким-либо корпоративным ресурсам вашей компании. Для выполнения этой задачи корпорация Майкрософт предлагает Microsoft Entra Business для клиентов (B2C).

Azure AD B2C предоставляет идентификацию клиентов как услугу. Вы можете разрешить пользователям использовать имя пользователя и пароль только для приложения. B2C поддерживает клиентов с удостоверениями социальных удостоверений для уменьшения паролей. Вы можете поддерживать корпоративных клиентов, федеративный каталог Azure AD B2C с идентификатором Microsoft Entra (или любым поставщиком удостоверений, поддерживающим SAML) в OpenID Подключение. В отличие от мультитенантного приложения, ваше приложение не использует корпоративный каталог клиента, где они защищают свои корпоративные активы. Клиенты могут получить доступ к вашей службе или возможности, не предоставляя приложению доступ к корпоративным ресурсам.

Это не только до разработчика

Хотя вы определяете в регистрации приложения, которые могут войти в приложение, последнее слово происходит от отдельного пользователя или администраторов домашнего клиента пользователя. Администраторы клиентов часто хотят иметь больше контроля над приложением, чем только кто может войти. Например, они могут применить политику условного доступа к приложению или контролировать группу, которую они позволяют использовать приложение. Чтобы администраторы клиентов могли иметь этот элемент управления, в платформа удостоверений Майкрософт есть второй объект: приложение Enterprise. Корпоративные приложения также называются субъектами-службами.

Для приложений с пользователями в других клиентах или других учетных записях потребителей

Как показано на схеме ниже, используя пример двух клиентов (для вымышленных организаций, Adatum и Contoso), поддерживаемые типы учетных записей включают учетные записи в любой параметр каталога организации для мультитенантного приложения, чтобы разрешить пользователям каталога организации. Другими словами, вы позволите пользователю войти в приложение с собственным удостоверением из любого идентификатора Microsoft Entra. Субъект-служба автоматически создается в клиенте, когда первый пользователь из клиента проходит проверку подлинности в приложении.

Анимированный GIF-файл показывает две схемы с переходом движения между первой схемой и второй схемой. Заголовок первой схемы: субъект-служба автоматически создается в клиенте, когда первый пользователь из клиента проходит проверку подлинности в приложении. Ниже первого заголовка схемы слева находятся две точки маркера: только одна регистрация приложения или объект приложения. Корпоративное приложение, субъект-служба в каждом клиенте, который позволяет пользователю входить в приложение. Слева от маркированных точек облачная фигура представляет клиент Adatum, где Adatum является именем вымышленной организации. Внутри облачной формы клиента Adatum значок представляет приложение, а другой значок представляет Adatum SP. Стрелка подключает значок приложения к значку службы. Второй заголовок схемы: администратор клиента управляет работой приложения в клиенте с приложением Enterprise для этого приложения. Под вторым заголовком схемы слева слева облачная фигура представляет клиент Adatum, где Adatum является именем вымышленной организации. Справа от облачной фигуры Adatum другая облачная фигура представляет клиент Contoso, в котором Contoso является именем вымышленной организации. В облачной форме Contoso значок представляет поставщик служб contoso. Стрелка подключает приложение Adatum внутри облачной формы Adatum к поставщику служб Contoso внутри облачной фигуры Contoso.

Существует только один объект регистрации приложения или приложения. Однако приложение Enterprise или субъект-служба (SP) в каждом клиенте позволяет пользователям входить в приложение. Администратор клиента может контролировать работу приложения в клиенте.

Рекомендации по мультитенантным приложениям

Мультитенантные приложения войдите пользователей из домашнего клиента пользователя, когда приложение использует общую или конечную точку организации. Приложение имеет одну регистрацию приложения, как показано на схеме ниже. В этом примере приложение регистрируется в клиенте Adatum. Пользователь A из Adatum и Пользователь B из Contoso может войти в приложение с ожиданием User A от Adatum будет получать доступ к данным Adatum, а пользователь B из Contoso получит доступ к данным Contoso.

Название схемы: мультитенантное приложение и внешние удостоверения, также известные как B2 B. Слева над зданием появляется "Adatum", представляющее организацию Adatum, где Adatum является именем вымышленной организации. Справа над зданием отображается "Contoso", представляющая организацию Contoso, в которой contoso является именем вымышленной организации. Справа от здания Adatum находится поле с заголовком Adatum App Registration. Он содержит значок, представляющий данные Adatum слева и значок, представляющий данные Contoso справа. Стрелка подключает здание Adatum к Adatum App Registration box. Внутри здания Adatum круг представляет пользователя A. Стрелка подключает пользователя A к Adatum App Registration box. Внутри здания Contoso круг представляет пользователя B. Стрелка подключает пользователя B к Adatum App Registration box. Текст в нижней части схемы между двумя зданиями: мультитенантное приложение. Использует общую конечную точку для входа. Приглашение или внешняя учетная запись не требуется.

В качестве разработчика вы несете ответственность за разделение сведений о клиенте. Например, если данные Contoso из Microsoft Graph, пользователь B из Contoso увидит только данные Microsoft Graph компании Contoso. Нет возможности для пользователя B из Компании Contoso получить доступ к данным Microsoft Graph в клиенте Adatum, так как Microsoft 365 имеет истинное разделение данных.

На приведенной выше схеме пользователь B из Contoso может войти в приложение и получить доступ к данным Contoso в приложении. Ваше приложение может использовать общие конечные точки (или организации), чтобы пользователь войдет в свой клиент, не требуя приглашения. Пользователь может выполнить и войти в приложение, и он будет работать после предоставления согласия администратора пользователя или клиента.

Совместная работа с внешними пользователями

Когда предприятия хотят разрешить пользователям, которые не являются членами предприятия, получать доступ к данным из предприятия, они используют функцию Microsoft Entra Business to Business (B2B). Как показано на схеме ниже, предприятия могут приглашать пользователей стать гостевыми пользователями в своем клиенте. После того как пользователь принимает приглашение, он может получить доступ к данным, защищенным приглашенным клиентом. Пользователь не создает отдельные учетные данные в клиенте.

Название схемы: мультитенантное приложение и внешние удостоверения, также известные как B2 B. Слева над зданием появляется "Adatum", представляющее организацию Adatum. В правой области "Contoso" отображается над зданием, представляющее организацию Contoso. Внутри здания Contoso находится круг, представляющий пользователя B. Справа от здания Adatum поле, содержащее значок, представляет Adatum Data and App Registration. Стрелка соединяет сборку Adatum с данными и полем регистрации. Внутри здания Adatum круг представляет пользователя A. Стрелка подключает пользователя A к данным и поле регистрации. Меньший круг внутри здания Adatum подключается со стрелкой к пользователю B и другой стрелкой к данным и поле регистрации. Текст в нижней части схемы между двумя зданиями: внешние удостоверения. Используйте Конечную точку Adatum для входа. Не удается использовать общую конечную точку. Требуется приглашение или внешняя учетная запись.

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

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

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

Следующие шаги

• Как и почему приложения добавляются в идентификатор Microsoft Entra ID , объясняется, как объекты приложений описывают приложение с идентификатором Microsoft Entra.
• Рекомендации по обеспечению безопасности свойств приложений в идентификаторе Microsoft Entra охватывают такие свойства, как URI перенаправления, маркеры доступа, сертификаты и секреты, URI идентификатора приложения и владение приложением.
• Создание приложений с использованием подхода "Нулевое доверие" к удостоверениям предоставляет общие сведения о разрешениях и рекомендациях по доступу.
• Получение авторизации для доступа к ресурсам помогает понять, как лучше всего обеспечить нулевое доверие при получении разрешений доступа к ресурсам для приложения.
• Разработка стратегии делегированных разрешений помогает реализовать оптимальный подход к управлению разрешениями в приложении и разработке с помощью принципов нулевого доверия.
• Разработка стратегии разрешений приложений помогает решить подход к управлению учетными данными приложения.