Estabelecer aplicativos no ecossistema Microsoft Entra ID

Ao criar aplicativos no Microsoft Entra ID, você primeiro 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 ter tokens emitidos para que os aplicativos acessem recursos.

Neste artigo, aprenda a registar aplicações num 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 desenvolvedores independentes de software (ISVs) podem criar e otimizar seus aplicativos para o Microsoft Entra ID. Nesta série, você pode saber mais sobre estes tópicos:

  • Microsoft Entra ID for Independent Software Developers descreve como usar esse serviço de gerenciamento de identidade e acesso baseado em nuvem para permitir que os funcionários acessem recursos com seu aplicativo.
  • Autenticar aplicativos e usuários descreve como os aplicativos usam o Microsoft Entra ID para autenticar usuários e aplicativos.
  • Autorizar aplicativos, recursos e cargas de trabalho ilustra quando humanos individuais interagem e direcionam um aplicativo, quando as APIs agem para um usuário e quando aplicativos ou serviços funcionam de forma independente.
  • Personalizar tokens ajuda você a criar segurança em aplicativos com tokens de ID e tokens de acesso do Microsoft Entra ID. Ele descreve as informações que você pode receber em tokens de ID do Microsoft Entra e como você pode personalizá-los.

Registar aplicações

Os desenvolvedores podem registrar aplicativos como aplicativos multilocatários e aplicativos de locatário único. Para os ISVs, recomendamos aplicações multilocatário. Um aplicativo multilocatário tem um único registro de aplicativo que um ISV controla e registra completamente em seu locatário. Saiba como pode criar uma entidade do Microsoft Entra ID para registar a sua aplicação.

Para fornecer soluções a qualquer cliente que execute o Microsoft Entra ID e tenha uma experiência perfeita para integração no locatário do Microsoft Entra ID do cliente, acesse Centro de administração do Microsoft Entra, Registos de aplicações, Registrar um aplicativo. Neste novo registo de aplicação, selecione Tipos de conta suportados, Contas em qualquer diretório organizacional (Qualquer inquilino do Microsoft Entra ID--Multilocatário) ou Contas em qualquer diretório organizacional (Qualquer inquilino do Microsoft Entra ID--Multilocatário) e contas pessoais da Microsoft (por exemplo, Skype, Xbox).

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

Integrar 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 faça login no aplicativo. Quando o locatário permite o consentimento do usuário (os usuários podem entrar em aplicativos sem que um administrador aprove previamente um aplicativo), a integração de um aplicativo exige apenas que um usuário entre no aplicativo. Este workshop de Identidade para Programadores (código de tempo 1:05:20 a 1:08:00) mostra uma aplicação a ser incorporada a um arrendatário à medida que um utilizador inicia sessão numa aplicação.

Quando você registra um aplicativo em um locatário do Microsoft Entra ID, ele recebe uma ID do aplicativo (ID do aplicativo) que também é conhecida como a ID do cliente de um aplicativo. É como um userid para um usuário, na medida em que 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 a ID do Microsoft Entra incluem a ID do aplicativo.

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

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

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

Exemplos de código de referência 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 que seja semelhante ao aplicativo que você está criando e leia 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 no Node.js, poderá encontrar exemplos que o levarão a estas instruções de registro.

Um registro de aplicativo comunica o que um desenvolvedor sabe. Em cada locatário a partir 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ário 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 permitam que usuários ou grupos específicos usem um aplicativo.

Para habilitar essas limitações, os administradores de locatários precisam de 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 designados 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 a partir do qual o usuário se autenticou. Os administradores de locatários podem usar o objeto principal 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 vincula-se ao registro do aplicativo. Você pode exibir atualizações para registros de aplicativos em Aplicativos Empresariais vinculados. Para aplicativos multilocatário, o cliente não tem acesso aos registros de aplicativos que permanecem no locatário do ISV. No entanto, um aplicativo pode acessar sua entidade de serviço usando o Microsoft Graph mesmo quando essa entidade de serviço está em um locatário diferente. Assim, um aplicativo pode acessar atributos sobre o Aplicativo Empresarial (por exemplo, se ele requer atribuição de usuário a um aplicativo ou os usuários atribuídos a uma função no aplicativo).

Embora recomendemos aplicativos multilocatários para registro de aplicativos para ISVs, um aplicativo de locatário único é outra opção para registrar aplicativos. Em vez de um único registo de aplicação no inquilino do ISV, onde o ISV controla completamente o registo, pode pedir aos seus clientes para registarem a sua aplicação no inquilino deles, para uso da sua aplicação. Depois de o cliente concluir o registo, configura a instância da aplicação com os detalhes do registo da aplicação. Recomendamos essa 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 se registrem e configurem seu aplicativo, não recomendamos aplicativos de locatário único para ISVs. No entanto, há cenários em que uma aplicação multilocatário não é viável para a sua aplicação.

Se o seu aplicativo usa SAML (Security Assertion Markup Language 2.0), em vez de OpenID Connect (OIDC) ou OAuth 2.0, ele segue um modelo de registo de aplicação de inquilino único. Para aplicações SAML, a ordem de criação dos principais de serviço e do registo de aplicações é o oposto de uma aplicação OIDC ou OAuth 2.0, pelo menos para o administrador que adiciona a aplicação SAML ao inquilino. 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 Enterprise. O Microsoft Entra ID cria automaticamente o registro do aplicativo. A galeria de aplicativos Microsoft Entra ID, descrita na seção Aplicativos de publicação, facilita o processo de criação de aplicativos SAML para administradores.

As limitações nos URIs (Identificadores Uniformes de Recursos) de redirecionamento podem impedir que um ISV crie uma aplicação multilocatária. Um aplicativo pode ter no máximo 256 URIs de redirecionamento, sem curingas. Se seu aplicativo exigir um URI de redirecionamento exclusivo para cada cliente e houver mais de 256 clientes exigindo uma instância exclusiva, talvez não seja possível criar um aplicativo multilocatário. Não é possível usar curingas (*) em URIs de redirecionamento de ID do Microsoft Entra 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, em seguida, redirecionaria o usuário para o ponto de extremidade específico do cliente.

Publicar aplicações

Quando os usuários inicialmente autenticam seu aplicativo ou autorizam um aplicativo a acessar um recurso para o usuário, eles decidem se confiam em seu aplicativo. Os administradores podem tomar decisões semelhantes para todos os usuários em seu locatário. Os administradores podem decidir se um utilizador inicia sessão numa aplicação e se uma aplicação acede a recursos específicos.

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

  • Publique seu aplicativo a partir de um domínio verificado. O domínio do editor informa aos usuários e administradores quais locais recebem suas informações. A publicação a partir de um domínio de editor verificado mostra que o locatário registrado de um aplicativo tem controle do domínio listado como editor de um aplicativo.
  • Publique seu aplicativo com a verificação do editor. Ter um domínio de editor verificado é um pré-requisito para a verificação do editor, que vai além de simplesmente mostrar que um editor de aplicativo tem controle sobre um domínio. A verificação do editor mostra que a Microsoft verificou a entidade por trás do domínio e do locatário como autêntica. Os utilizadores que não são administradores muitas vezes não confiam em aplicações multilocatárias de editores não verificados. Os administradores podem configurar locatários para que os aplicativos que não são de editores verificados sempre exijam o consentimento do administrador. A verificação do editor destina-se principalmente a ISVs que desenvolvem aplicações multitenant no OAuth 2.0 e OIDC. Os editores verificados são membros do Microsoft Cloud Partner Program. A verificação do editor não afeta os aplicativos de locatário único, tais como aqueles que usam SAML ou aplicativos de Linha de Negócios.
  • Publique seu aplicativo na galeria de aplicativos do Microsoft Entra ID. Você pode solicitar que a Microsoft liste seus aplicativos usando SAML 2.0 e aqueles que usam OAuth 2.0 e OIDC na galeria de aplicativos do Microsoft Entra ID. Os administradores encontram aplicações pré-integradas na galeria de aplicações do Microsoft Entra ID a partir do centro de administração do Microsoft Entra, Aplicações Empresariais, Novas Aplicações. Publicar seu aplicativo na galeria de aplicativos do Microsoft Entra ID simplifica e minimiza a configuração do seu aplicativo. A Microsoft testa os aplicativos e fornece verificação de compatibilidade, especialmente valiosa para aplicativos que usam SAML 2.0 que exigem configuração antes do uso. Você pode usar a implementação do System for Cross-Domain Identity Management (SCIM) 2.0 do seu aplicativo para configurar seu aplicativo de galeria para provisionamento. Consulte a seção Provisionamento automático. Para começar, envie uma solicitação para publicar seu aplicativo. Você pode obter logon único e provisionamento de usuário usando SCIM com um único aplicativo na galeria de aplicativos.
  • Participe do Programa de Conformidade de Aplicativos Microsoft 365. Usar um domínio verificado mostra que você tem controle sobre seu domínio. A verificação do editor mostra que a Microsoft verificou a sua organização como autêntica. Listar seu aplicativo na galeria de aplicativos do Microsoft Entra ID mostra que seu aplicativo funciona com o Microsoft Entra ID para facilitar a integração. O Programa de Conformidade do Microsoft 365 permite que você informe seus clientes sobre a segurança e a conformidade do seu aplicativo por meio do Atestado do Editor, da Certificação Microsoft 365 ou da ACAT (App Compliance Automation Tool) no Azure. Ele mostra como seu aplicativo protege os recursos que o cliente autoriza seu aplicativo a acessar.

Aprovisionamento 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 em nuvem que os usuários precisam acessar. Além de criar objetos de usuário e grupo, o provisionamento automático inclui manutenção e remoção de identidade do usuário à medida que o status ou as funções mudam. O serviço de provisionamento Microsoft Entra provisiona automaticamente utilizadores e grupos para aplicações chamando um endpoint da API de gestão de objetos SCIM fornecido por uma aplicação.

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 suportem SCIM. A maioria dos IdPs suporta o 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 um 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 SCIM.
  • Criar 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 pull para monitorar o Microsoft Entra ID em busca de alterações. Quando se implementa um ponto de extremidade SCIM, o Microsoft Entra ID gestiona o serviço de provisionamento e envia as alterações para a sua aplicação.

Usar SCIM, Microsoft Graph e Microsoft Entra ID para provisionar usuários e enriquecer aplicativos com dados fornece orientação sobre quando usar SCIM e quando usar o Microsoft Graph. Documentação da Microsoft para utilizadores a fim de planear, construir e validar o seu ponto de extremidade SCIM com o Microsoft Entra ID, e abordar questões conhecidas de conformidade com 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 orientado por RH é o processo de criação de identidades digitais com base em uma solução de recursos humanos. Os sistemas de RH tornam-se o ponto de partida para essas identidades digitais recém-criadas e, muitas vezes, são o ponto de partida para inúmeros processos de provisionamento. As soluções de RH locais podem usar o Microsoft Identity Manager para provisionar usuários em um Ative Directory local. Eles podem então sincronizar com o Microsoft Entra ID com o Microsoft Entra Connect ou diretamente com o Microsoft Entra ID.

Com o provisionamento de entrada orientado 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 ID do Microsoft Entra e para domínios do Ative Directory locais conectados. Por exemplo, um aplicativo de RH ou um aplicativo de sistemas de informações para estudantes 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 , aprenda os conceitos de provisionamento de entrada orientados por API, investigue a funcionalidade bulkUpload no Microsoft Graph e familiarize-se com os conceitos, cenários e limitações de provisionamento orientado por API.

Próximos passos

  • Last updated on