Compartilhar via

Estabelecer aplicativos no ecossistema do Microsoft Entra ID

  • Artigo

Ao criar aplicativos no Microsoft Entra ID, primeiro você estabelece uma identidade para um aplicativo. Um aplicativo precisa de uma identidade no Microsoft Entra ID para solicitar tokens. Uma interface de programação de aplicativo (API) precisa de uma identidade no Microsoft Entra ID para que os tokens sejam emitidos para que os aplicativos acessem os recursos.

Neste artigo, saiba como registrar aplicativos em um locatário do Microsoft Entra ID no Centro de administração do Microsoft Entra ou com a API do Microsoft Graph. É o segundo de uma série de artigos sobre como os ISVs (desenvolvedores de software independentes) podem criar e otimizar seus aplicativos para o Microsoft Entra ID. Nesta série, você pode saber mais sobre estes tópicos:

Registrar aplicativos

Os desenvolvedores podem registrar aplicativos como aplicativos multilocatário e aplicativos de locatário único. Para ISVs, recomendamos aplicativos multilocatário. Um aplicativo multilocatário tem um único registro de aplicativo que um ISV controla completamente e registra em seu locatário. Saiba como você pode criar um locatário do Microsoft Entra ID para registrar o seu aplicativo.

Para fornecer soluções para qualquer cliente que esteja executando o Microsoft Entra ID e ter uma experiência perfeita para integração ao locatário do Microsoft Entra ID do cliente, acesse Centro de administração do Microsoft Entra, Registros de aplicativo, Registrar um aplicativo. Neste novo registro de aplicativo, selecione Tipos de conta com suporte, Contas em qualquer diretório organizacional (qualquer locatário do Microsoft Entra ID--Multilocatário) ou Contas em qualquer diretório organizacional (qualquer locatário do Microsoft Entra ID --Multilocatário) e contas Microsoft pessoais (por exemplo, Skype, Xbox).

Captura de tela das opções de configuração no centro de administração do Microsoft Entra.

A integração de um aplicativo multilocatário a um locatário externo pode ser tão simples quanto executar um aplicativo e fazer com que um usuário entre no aplicativo. Quando o locatário permite o consentimento do usuário (os usuários podem entrar em aplicativos sem que um administrador aprove anteriormente um aplicativo), a integração de um aplicativo requer apenas que um usuário entre no aplicativo. Este Workshop de identidade para desenvolvedores (código de horário 1:05:20 a 1:08:00) mostra um aplicativo sendo integrado a um locatário à medida que um usuário entra em um aplicativo.

Quando você registra um aplicativo em um locatário do Microsoft Entra ID, ele recebe uma ID do Aplicativo (App ID) que também é conhecida como a ID do cliente de um aplicativo. Ele é como um userid para um usuário na medida em que ele identifica exclusivamente um aplicativo. A ID do Aplicativo é globalmente exclusiva na nuvem do Microsoft Entra ID e imutável. Todas as interações entre um aplicativo e o Microsoft Entra ID incluem a ID do aplicativo.

Além da ID do Aplicativo, um registro de aplicativo contém informações sobre o aplicativo que os desenvolvedores do aplicativo conhecem ou precisam saber. Por exemplo, um desenvolvedor de aplicativos precisa saber a ID do aplicativo para interagir com o Microsoft Entra ID. O desenvolvedor sabe o tipo de aplicativo que está criando (aplicativo Web, aplicativo nativo, aplicativo de página única, aplicativo móvel ou aplicativo da área de trabalho). Os tipos de aplicativo têm atributos necessários.

Por exemplo, um atributo de aplicativo necessário é um Uniform Resource Identifier (URI) de redirecionamento. O atributo informa ao Microsoft Entra ID o endereço da Web ou o endereço do aplicativo nativo para enviar a um usuário após a autenticação ou autorização. O desenvolvedor conhece os URIs de redirecionamento para um aplicativo, com base no tipo de aplicativo e no local em que o aplicativo é executado.

O manifesto de um aplicativo (que você acessa do centro de administração do Microsoft Entra ou com uma API do Microsoft Graph) armazena muitos atributos de aplicativo. Confira Noções básicas sobre o manifesto do aplicativo do Microsoft Entra para saber mais sobre atributos de aplicativo e seus valores permitidos.

Confira Exemplos de código para autenticação e autorização da plataforma de identidade da Microsoft para descobrir as configurações recomendadas para aplicativos que você está desenvolvendo. Encontre um exemplo de aplicativo semelhante ao aplicativo que você está criando e leia a sua documentação. Exemplos detalham as configurações de registro de aplicativo necessárias por tipo de aplicativo. Por exemplo, se você estiver criando uma API em Node.js, poderá encontrar exemplos que levem você a essas instruções de registro.

Um registro de aplicativo comunica o que um desenvolvedor sabe. Em cada locatário do qual os usuários podem se autenticar em seu aplicativo multilocatário, os administradores de locatários configuram como os aplicativos são executados em seu locatário. Por exemplo, um administrador de locatários pode definir uma política de acesso condicional que limita um aplicativo a locais de rede específicos. Além disso, pode haver uma política de acesso condicional para exigir autenticação multifator (MFA) para um usuário acessar um aplicativo ou configurações de aplicativo que permitem que usuários ou grupos específicos usem um aplicativo.

Para habilitar essas limitações, os administradores de locatário precisam ter pontos de controle para aplicativos em seu locatário. O Microsoft Entra ID cria automaticamente um aplicativo empresarial em cada locatário no qual um usuário autentica um aplicativo. No centro de administração do Microsoft Entra, eles são chamados de Aplicativos empresariais, mas os objetos são entidades de serviço. Saiba mais sobre Aplicativos e entidades de serviço no Microsoft Entra ID.

Depois que um usuário autentica um aplicativo, o Microsoft Entra ID cria uma entidade de serviço no locatário do qual o usuário se autenticou. Os administradores de locatário podem usar o objeto da entidade de serviço no Microsoft Graph (ou no Centro de administração do Microsoft Entra, Aplicativos empresariais) para configurar como um aplicativo pode funcionar no locatário.

As entidades de serviço não são cópias de um registro de aplicativo, embora tenham muitos dos mesmos atributos. Em vez disso, uma entidade de serviço é vinculada ao seu próprio registro do aplicativo. Você pode exibir atualizações para registros de aplicativo nos aplicativos empresariais vinculados. Para aplicativos multilocatário, o cliente não tem acesso aos registros de aplicativo que permanecem no locatário do ISV. No entanto, um aplicativo poderá acessar sua entidade de serviço usando o Microsoft Graph mesmo quando essa entidade de serviço estiver em um locatário diferente. Assim, um aplicativo poderá acessar atributos sobre o aplicativo empresarial (por exemplo, se ele exige atribuição de usuário a um aplicativo, ou os usuários atribuídos a uma função no aplicativo).

Embora recomendemos aplicativos multilocatário para registro de aplicativo para ISVs, um único aplicativo de locatário é outra opção para registrar aplicativos. Em vez de um único registro de aplicativo no locatário do ISV em que o ISV controla completamente o registro, você pode pedir aos clientes que registrem o seu aplicativo em seus locatários para o seu aplicativo. Depois que o cliente concluir o registro, ele configurará a instância do aplicativo com os detalhes do registro do aplicativo. Recomendamos esta abordagem de aplicativo de locatário único principalmente para aplicativos de linha de negócios desenvolvidos para empresas específicas.

Devido à sobrecarga para que os clientes registrem e configurem seu aplicativo, não recomendamos aplicativos de locatário único para ISVs. No entanto, há cenários para os quais um aplicativo multilocatário não é possível para o seu aplicativo.

Se o seu aplicativo usa Security Assertion Markup Language (SAML) 2.0, em vez de OpenID Connect (OIDC) ou OAuth 2.0, ele segue um modelo de registro de aplicativo de locatário único. Para aplicativos SAML, a ordem de criação de entidades de serviço e registro de aplicativo é o oposto de um aplicativo OIDC ou OAuth 2.0, pelo menos para o administrador que adiciona o aplicativo SAML ao locatário. Em vez de registrar um aplicativo e fazer com que o Microsoft Entra ID crie automaticamente a entidade de serviço, os administradores começam criando um aplicativo empresarial. O Microsoft Entra ID cria automaticamente o registro do aplicativo. A galeria de aplicativos do Microsoft Entra ID, descrita na seção Publicação de aplicativos, facilita o processo de criação do aplicativo SAML para administradores.

As limitações em URIs (Uniform Resource Identifiers) podem impedir que um ISV crie um aplicativo multilocatário. Um aplicativo pode ter no máximo 256 URIs de redirecionamento, sem curingas. Se o aplicativo exigir um URI de redirecionamento exclusivo para cada cliente e houver mais de 256 clientes exigindo uma instância exclusiva, talvez você não consiga criar um aplicativo multilocatário. Você não pode usar curingas (*) nos URIs de redirecionamento do Microsoft Entra ID por motivos de segurança. Uma opção é ter um único URI de redirecionamento para o seu serviço central (se um serviço central for possível). O URI de redirecionamento central validaria o token e redirecionaria o usuário para o ponto de extremidade específico do cliente.

Publicar aplicativos

Quando os usuários autenticam inicialmente o seu aplicativo ou autorizam um aplicativo a acessar um recurso para o usuário, eles decidem se confiam no seu aplicativo. Os administradores podem tomar decisões semelhantes para todos os usuários em seu locatário. Os administradores podem decidir se um usuário entra em um aplicativo e se um aplicativo acessa recursos específicos.

Os métodos de publicação de aplicativo a seguir podem ajudar os ISVs a apresentar seus aplicativos como merecedores de confiança dos usuários e administradores.

  • Publique seu aplicativo a partir de um domínio verificado. O domínio do publicador informa aos usuários e administradores quais locais recebem suas informações. Publicar de um domínio de publicador verificado mostra que o locatário registrado de um aplicativo tem o controle do domínio listado como publicador de aplicativo.
  • Publique o seu aplicativo com verificação de publicador. Ter um domínio de publicador verificado é pré-requisito para a verificação de publicador, que vai além de simplesmente mostrar que um publicador de aplicativo tem controle sobre um domínio. A verificação de publicador mostra que a Microsoft verificou a entidade por trás do domínio e do locatário como autenticada. Usuários que não são administradores geralmente não confiam em aplicativos multilocatário de publicadores não verificados. Os administradores podem configurar locatários para que os aplicativos que não são de publicadores verificados sempre exijam consentimento do administrador. A verificação de publicador é principalmente para ISVs que criam aplicativos multilocatário no OAuth 2.0 e no OIDC. Os publicadores verificados são membros do Microsoft Cloud Partner Program. A verificação de publicador não afeta aplicativos de locatário único, como aqueles que usam aplicativos da SAML ou de linha de negócios.
  • Publique o seu aplicativo na galeria de aplicativos do Microsoft Entra ID. Você pode solicitar que a Microsoft liste seus aplicativos que usam SAML 2.0 e aqueles que usam OAuth 2.0 e OIDC na galeria de aplicativos do Microsoft Entra ID. Os administradores encontram aplicativos pré-integrados na galeria de aplicativos do Microsoft Entra ID em centro de administração do Microsoft Entra, Aplicativos empresariais, Novos aplicativos. Publicar o seu aplicativo na galeria de aplicativos do Microsoft Entra ID simplifica e minimiza a configuração do aplicativo. A Microsoft testa os aplicativos e fornece verificação de compatibilidade, o que é especialmente valioso para aplicativos que usam SAML 2.0 com exigência de configuração antes do uso. Você pode usar a implementação do Sistema de Gerenciamento de Usuários entre Domínios (SCIM) 2.0 do aplicativo para configurar o aplicativo da galeria de aplicativos para provisionamento Confira a seção Provisionamento automático. Para começar, envie uma solicitação para publicar o seu aplicativo. Você pode obter o logon único e o provisionamento de usuário usando o SCIM com um único aplicativo na galeria de aplicativos.
  • Participe do Programa de conformidade de aplicativos do Microsoft 365. O uso de um domínio verificado mostra que você tem controle sobre o seu domínio. A verificação de publicador mostra que a Microsoft autenticou a sua organização. Listar o seu aplicativo na galeria de aplicativos do Microsoft Entra ID mostra que seu aplicativo funciona com o Microsoft Entra ID, para fácil integração. O Programa de conformidade do Microsoft 365 permite que você informe seus clientes sobre a segurança e a conformidade do aplicativo pelo Atestado do publicador, pela Certificação do Microsoft 365 ou pela Ferramenta de automação de conformidade do aplicativo (ACAT) no Azure. Ela mostra como o seu aplicativo protege os recursos que o cliente autoriza o seu aplicativo a acessar.

Provisionamento automático

O provisionamento de aplicativos no Microsoft Entra ID pode provisionar automaticamente identidades de usuário, objetos de grupo e funções para aplicativos de nuvem que os usuários precisam acessar. Além de criar objetos de usuário e grupo, o provisionamento automático inclui a manutenção e remoção de identidade do usuário à medida que o status ou as funções mudam. O serviço de provisionamento do Microsoft Entra provisiona automaticamente usuários e grupos para aplicativos chamando um ponto de extremidade da API de gerenciamento de objetos SCIM fornecido por um aplicativo.

Para ISVs, as vantagens do provisionamento de aplicativos no Microsoft Entra ID incluem o seguinte.

  • O provisionamento para o seu aplicativo com o Microsoft Graph é possível; a criação de um ponto de extremidade SCIM permite que o provisionamento funcione com provedores de identidade (IdPs) que dão suporte ao SCIM. A maioria dos IdPs dá suporte ao protocolo de provisionamento SCIM.
  • O provisionamento é uma operação de sincronização em que os dados são sincronizados entre o Microsoft Entra ID e um aplicativo. Para implementar uma solução de sincronização baseada no Microsoft Graph, um aplicativo requer acesso a todos os atributos de todos os usuários e grupos no locatário. Alguns clientes do Microsoft Entra ID estão relutantes em permitir acesso tão amplo. Com o SCIM, um administrador pode selecionar quais atributos o Microsoft Entra ID sincroniza com um aplicativo. Muitos administradores preferem poder ter esse controle refinado que só está disponível com uma implementação do SCIM.
  • Criar o seu próprio serviço de sincronização do Microsoft Graph para provisionamento significa que você deve gerenciar esse serviço e implementar um modelo de pull para monitorar alterações no Microsoft Entra ID. Quando você implementa um ponto de extremidade SCIM, o Microsoft Entra ID gerencia o gerenciamento do serviço de provisionamento e envia alterações por push ao seu aplicativo.

Usar o SCIM, o Microsoft Graph e o Microsoft Entra ID para provisionar usuários e enriquecer aplicativos com dados fornece diretrizes sobre quando usar o SCIM e quando usar o Microsoft Graph. Documentação da Microsoft do usuário para planejar, compilar e validar o seu ponto de extremidade SCIM com o Microsoft Entra ID e resolver problemas conhecidos de conformidade com o SCIM.

Além de sincronizar dados com aplicativos, o Microsoft Entra ID oferece provisionamento com aplicativos de recursos humanos (RH) baseados em nuvem. O provisionamento controlado por RH é o processo de criação de identidades digitais com base em uma solução de recursos humanos. Os sistemas de RH se tornam o início da autoridade para essas identidades digitais recém-criadas e geralmente são o ponto de partida para vários processos de provisionamento. As soluções de RH locais podem usar o Microsoft Identity Manager para provisionar usuários para um Active Directory local. Em seguida, eles podem sincronizar com o Microsoft Entra ID com o Microsoft Entra Connect ou diretamente com o Microsoft Entra ID.

Com o provisionamento de entrada controlado por API, os ISVs de RH baseados em nuvem podem enviar experiências de sincronização nativas para que as alterações no sistema de RH fluam automaticamente para o Microsoft Entra ID e domínios do Active Directory locais conectados. Por exemplo, um aplicativo de RH ou um aplicativo de sistemas de informações de alunos pode enviar dados para o Microsoft Entra ID assim que uma transação for concluída ou como atualização em massa no final do dia. Para começar a aprender sobre os conceitos de provisionamento de entrada controlados por API, investigue a funcionalidade bulkUpload no Microsoft Graph e familiarize-se mais com os conceitos, cenários e limitações de provisionamento controlados por API.

Próximas etapas