Tipos de identidade e conta para aplicativos de locatário único e multilocatário

Este artigo explicará como você, como desenvolvedor, pode escolher se seu aplicativo permite apenas usuários do locatário do Microsoft Entra, qualquer locatário do Microsoft Entra ou usuários com contas pessoais da Microsoft. Você pode configurar seu aplicativo para ser um único locatário ou multilocatário durante o registro do aplicativo no Azure. Garanta o princípio de Confiança Zero de acesso com privilégios mínimos para que seu aplicativo solicite apenas as permissões necessárias.

A plataforma de identidade da Microsoft fornece suporte para tipos de identidade específicos:

• Contas corporativas ou de estudante quando a entidade tem uma conta em uma ID do Microsoft Entra
• Contas pessoais da Microsoft (MSA) para qualquer pessoa que tenha conta no Outlook.com, Hotmail, Live, Skype, Xbox, etc.
• Identidades externas no Microsoft Entra ID para parceiros (usuários fora da sua organização)
• Microsoft Entra Business to Customer (B2C) que permite criar uma solução que permitirá que seus clientes tragam seus outros provedores de identidade. Os aplicativos que usam o Azure AD B2C ou estão inscritos no Microsoft Dynamics 365 Fraud Protection com Azure Active Directory B2C podem avaliar atividades potencialmente fraudulentas após tentativas de criar novas contas ou entrar no ecossistema do cliente.

Uma parte necessária do registro do aplicativo na ID do Microsoft Entra é a seleção dos tipos de conta com suporte. Enquanto os profissionais de TI em funções de administrador decidem quem pode consentir com aplicativos no seu locatário, você, como desenvolvedor, especifica quem pode usar seu aplicativo com base no tipo de conta. Quando um locatário não permite que você registre seu aplicativo no Microsoft Entra ID, os administradores fornecerão uma maneira de comunicar esses detalhes a eles por meio de outro mecanismo.

Você escolherá entre as seguintes opções de tipo de conta com suporte ao registrar seu aplicativo.

• 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

Somente as contas deste diretório organizacional - locatário único

Ao selecionar Contas somente nesse diretório organizacional (somente O365 - Locatário único), você permite que apenas usuários e convidados do locatário em que o desenvolvedor registrou seu aplicativo. Essa opção é a mais comum para aplicativos de linha de negócios (LOB).

Somente contas em qualquer diretório organizacional - multilocatário

Ao selecionar Contas em qualquer diretório organizacional (Qualquer diretório do Microsoft Entra - Multilocatário), você permite que qualquer usuário de qualquer diretório do Microsoft Entra entre no aplicativo multilocatário. Se quiser permitir apenas usuários de locatários específicos, filtrará esses usuários no seu código verificando se a declaração tid no id_token está na lista de locatários permitidos. Seu aplicativo pode utilizar o ponto de extremidade da organização ou o ponto de extremidade comum para entrar usuários no locatário inicial do usuário. Para oferecer suporte a usuários convidados que entram no seu aplicativo multilocatário, você usará o ponto de extremidade de locatário específico para o locatário em que o usuário é convidado para entrar no usuário.

Contas em qualquer conta institucional e contas pessoais da Microsoft

Quando você seleciona Contas em qualquer conta institucional e contas Microsoft pessoais (Qualquer diretório do Microsoft Entra - Multilocatário) e contas Microsoft pessoais (por exemplo, Skype, Xbox), você permite que um usuário entre no seu aplicativo com sua identidade nativa de qualquer locatário ou conta de consumidor do Microsoft Entra. A mesma filtragem de locatário e o uso de ponto de extremidade são aplicáveis a esses aplicativos como são aplicáveis aos aplicativos multilocatário, conforme descrito acima.

Somente contas Microsoft pessoais

Ao selecionar Somente contas Microsoft pessoais, você permite que apenas usuários com contas de consumidor usem seu aplicativo.

Aplicativos voltados para o cliente

Quando você cria uma solução na plataforma de identidade da Microsoft que alcança seus clientes, geralmente não deseja utilizar seu diretório corporativo. Em vez disso, você deseja que os clientes estejam em um diretório separado para que não possam acessar nenhum dos recursos corporativos da sua empresa. Para atender a essa necessidade, a Microsoft oferece o Microsoft Entra Business to Customer (B2C).

O Azure AD B2C fornece a identidade de empresa para cliente como um serviço. É possível permitir que os usuários tenham um nome de usuário e senha apenas para seu aplicativo. O B2C oferece suporte a clientes com identidades sociais para reduzir senhas. É possível oferecer suporte a clientes corporativos federando seu diretório B2C do Azure AD para a ID do Microsoft Entra de seus clientes (ou qualquer provedor de identidade que ofereça suporte a SAML) para o OpenID Connect. Ao contrário de um aplicativo multilocatário, seu aplicativo não utiliza o diretório corporativo do cliente onde ele está protegendo seus ativos corporativos. Seus clientes podem acessar seu serviço ou recurso sem conceder ao aplicativo acesso aos recursos corporativos deles.

Não depende apenas do desenvolvedor

Embora você defina no registro do aplicativo quem pode entrar no aplicativo, a palavra final vem do usuário individual ou dos administradores do locatário inicial do usuário. Os administradores de locatários geralmente querem ter mais controle sobre um aplicativo do que apenas quem pode entrar. Por exemplo, eles podem querer aplicar uma política de Acesso Condicional ao aplicativo ou controlar qual grupo eles permitem utilizar o aplicativo. Para permitir que os administradores de locatários tenham esse controle, há um segundo objeto na plataforma de identidade da Microsoft: o aplicativo Enterprise. Aplicativos corporativos também são conhecidos como Entidades de Serviço.

Para aplicativos com usuários em outros locatários ou outras contas de consumidor

Como mostra o diagrama abaixo utilizando um exemplo de dois locatários (para as organizações fictícias Adatum e Contoso), os tipos de conta com suporte incluem a opção Contas em qualquer diretório organizacional para um aplicativo multilocatário, para que você possa permitir usuários do diretório organizacional. Em outras palavras, você permitirá que um usuário entre no seu aplicativo com sua identidade nativa de qualquer ID do Microsoft Entra. Uma entidade de serviço é criada automaticamente no locatário quando o primeiro usuário de um locatário se autentica no aplicativo.

O GIF animado mostra dois diagramas com uma transição de movimento entre o primeiro diagrama e o segundo diagrama. Primeiro título do diagrama: a entidade de serviço é criada automaticamente no locatário quando o primeiro usuário de um locatário se autentica no aplicativo. Abaixo do primeiro título do diagrama, à esquerda, estão dois marcadores: Apenas um registro de aplicativo ou objeto de aplicativo. Aplicativo corporativo, Service Principal, em cada locatário que permite que o usuário entre no aplicativo. À esquerda dos marcadores, uma forma de nuvem representa o locatário Adatum, onde Adatum é o nome de uma organização fictícia. Dentro da forma de nuvem do locatário Adatum, um ícone representa o Aplicativo e outro ícone representa o SP Adatum. Uma seta conecta o ícone do aplicativo ao ícone da controladora de armazenamento. Título do segundo diagrama: O administrador do locatário controla como o aplicativo funciona no seu locatário com o aplicativo Enterprise para esse aplicativo. Abaixo do segundo título do diagrama, à esquerda, uma forma de nuvem representa o locatário Adatum, onde Adatum é o nome de uma organização fictícia. À direita da forma de nuvem Adatum, outra forma de nuvem representa o locatário da Contoso, onde Contoso é o nome de uma organização fictícia. Dentro da forma de nuvem da Contoso, um ícone representa a controladora de armazenamento da Contoso. Uma seta conecta o aplicativo Adatum dentro da forma de nuvem Adatum à controladora de armazenamento Contoso dentro da forma de nuvem Contoso.

Há apenas um registro de aplicativo ou objeto de aplicativo. No entanto, um aplicativo Enterprise, ou SP (Service Key, entidade de serviço), em cada locatário permite que os usuários entrem no aplicativo. O administrador do locatário pode controlar como o aplicativo funciona no seu locatário.

Considerações sobre aplicativos multilocatário

Os aplicativos multilocatários entram em usuários do locatário inicial do usuário quando o aplicativo utiliza o ponto de extremidade comum ou da organização. O aplicativo tem um registro de aplicativo, conforme mostrado no diagrama abaixo. Neste exemplo, o aplicativo está registrado no locatário Adatum. O usuário A da Adatum e o usuário B da Contoso podem entrar no aplicativo com a expectativa de que o usuário A da Adatum acesse os dados da Adatum e que o usuário B da Contoso acesse os dados da Contoso.

Título do diagrama: Aplicativo Multilocatário vs. Identidades Externas, também conhecido como B 2 B. À esquerda, 'Adatum' aparece acima de um edifício para representar a organização Adatum, onde Adatum é o nome de uma organização fictícia. À direita, 'Contoso' aparece acima de um edifício para representar a organização Contoso onde Contoso é o nome de uma organização fictícia. À direita do edifício Adatum está uma caixa com o título, Adatum App Registration. Ele contém um ícone que representa os Dados Adatum à esquerda e um ícone que representa os Dados Contoso à direita. Uma seta conecta o edifício Adatum à caixa Registro de aplicativo Adatum. Dentro do edifício Adatum, um círculo representa o Usuário A. Uma seta conecta o Usuário A à caixa Registro do Aplicativo Adatum. Dentro do edifício da Contoso, um círculo representa o Usuário B. Uma seta conecta o Usuário B à caixa Registro do Aplicativo Adatum. Texto na parte inferior do diagrama, entre os dois edifícios: Aplicativo multilocatário. Usa ponto de extremidade comum para iniciar sessão Não é necessário convite/conta externa.

Como desenvolvedor, é sua responsabilidade manter as informações do locatário separadas. Por exemplo, se os dados da Contoso forem do Microsoft Graph, o Usuário B da Contoso verá apenas os dados do Microsoft Graph da Contoso. Não há possibilidade para o Usuário B da Contoso acessar dados do Microsoft Graph no locatário Adatum porque o Microsoft 365 tem separação de dados verdadeira.

No diagrama acima, o Usuário B da Contoso pode entrar no aplicativo e acessar os dados da Contoso no seu aplicativo. Seu aplicativo pode usar nossos pontos de extremidade comuns (ou da organização) para que o usuário entre nativamente no seu locatário, não exigindo nenhum processo de convite. Um usuário pode executar e entrar no seu aplicativo e ele funcionará depois que o usuário ou o administrador do locatário conceder consentimento.

Colaboração com usuários externos

Quando as empresas desejam permitir que usuários que não são membros da empresa acessem dados da empresa, elas usam o recurso Microsoft Entra Business to Business (B2B). Conforme ilustrado no diagrama abaixo, as empresas podem convidar usuários para se tornarem usuários convidados no seus locatários. Depois que o usuário aceitar o convite, ele poderá acessar os dados que o locatário convidado protegeu. O usuário não cria uma credencial separada no locatário.

Título do diagrama: Aplicativo Multilocatário vs. Identidades Externas, também conhecido como B 2 B. À esquerda, 'Adatum' aparece acima de um edifício para representar a organização Adatum. À direita, 'Contoso' aparece acima de um edifício para representar a organização Contoso. Dentro do edifício da Contoso há um círculo que representa o Usuário B. À direita do edifício Adatum, uma caixa contendo um ícone representa os Dados Adatum e o Registro de Aplicativos. Uma seta conecta o edifício Adatum à caixa de dados e registro. Dentro do edifício Adatum, um círculo representa o Usuário A. Uma seta conecta o Usuário A à caixa de dados e registro. Um círculo menor dentro do edifício Adatum se conecta com uma seta para o Usuário B e com outra seta para a caixa de dados e registro. Texto na parte inferior do diagrama, entre os dois edifícios: Identidades Externas. Utilize o ponto de extremidade Adatum para entrar. Não é possível utilizar ponto de extremidade comum. Convite/conta externa necessária.

Os usuários convidados se autenticam entrando no seu locatário residencial, conta pessoal da Microsoft ou outra conta IDP. Os hóspedes também podem autenticar-se com um código de acesso único utilizando qualquer e-mail. Depois que os convidados se autenticam, a ID do Microsoft Entra do locatário convidativo fornece um token para acesso aos dados do locatário convidado.

Como desenvolvedor, tenha em mente estas considerações quando seu aplicativo oferecer suporte a usuários convidados:

• Você deve utilizar um ponto de extremidade específico do locatário ao entrar no usuário convidado. Não é possível utilizar os pontos de extremidade comuns, organizacionais ou de consumidor.
• A identidade do usuário convidado é diferente da identidade do usuário no seu locatário doméstico ou outro IDP. A declaração oid no token de um usuário convidado será diferente da oid do mesmo indivíduo em seu locatário residencial.

Próximas etapas

• O artigo Como e por que aplicativos são adicionados ao Microsoft Entra ID explica como objetos de aplicativo descrevem um aplicativo para o Microsoft Entra ID.
• O artigo Práticas recomendadas de segurança para propriedades de aplicativos no Microsoft Entra ID abrange propriedades como URI de redirecionamento, tokens de acesso, certificados e segredos, URI de ID de aplicativo e propriedade de aplicativos.
• O artigo Criar aplicativos com uma abordagem de identidade de Confiança Zero fornece uma visão geral das permissões e das práticas recomendadas de acesso.
• O artigo Adquirir autorização para acessar recursos ajuda a entender a melhor maneira de garantir a Confiança Zero ao adquirir permissões de acesso a recursos para um aplicativo.
• O artigo Desenvolver uma estratégia de permissões delegadas ajuda você a implementar a melhor abordagem para gerenciar permissões em um aplicativo e a desenvolver com o uso dos princípios de Confiança Zero.
• O artigo Desenvolver uma estratégia de permissões de aplicativo ajuda você a decidir sobre uma abordagem de permissões de aplicativos para o gerenciamento de credenciais.