Na verdade, a maioria das pessoas pensa que identidade é apenas o nome de usuário 100. Você digita, obtém acesso e pronto. Mas quando você é uma empresa atendendo clientes, a identidade fica muito mais complicada. O que acontece quando seu aplicativo precisa permitir que milhares de pessoas se cadastrem ou entrem com suas contas do Google em vez de criar mais uma senha? E como manter todos esses dados de clientes seguros sem misturá-los com o diretório de funcionários? Esse é exatamente o problema que o Microsoft Entre External ID foi criado para resolver. A questão. Ele está substituindo o Azure AD B2C completamente. Ao final deste episódio, você entenderá o que o External ID realmente é, as três principais formas de usá-lo e por que ele é importante para qualquer aplicativo voltado ao cliente.

Imagine que há 20 anos você criou um aplicativo para clientes. Naquela época, você criava seu próprio sistema de login, escrevia o código para senhas, configurava um banco de dados para armazená-las, criava o fluxo de esqueci minha senha, tudo do zero. Isso funcionava bem para um aplicativo pequeno com algumas centenas de usuários, mas à medida que os aplicativos cresciam, as coisas ficavam complicadas rapidamente. As empresas precisavam permitir que os usuários entrassem com o Google ou o Facebook, precisavam de autenticação multifator, precisavam lidar com milhões de contas sem falhar. Construir tudo isso sozinho tornou-se um pesadelo. A primeira resposta da Microsoft foi o Azure AD B2C. Era um serviço de identidade de cliente e, na época, resolvia um problema real. Mas é aqui que a dor começou. O maior problema era algo chamado políticas personalizadas. Essas políticas eram escritas em XML.

Se você já trabalhou com arquivos XML que ocupam centenas de linhas, sabe exatamente como isso é doloroso. Difícil de configurar, difícil de depurar e, quando algo quebrava, boa sorte tentando descobrir o motivo. Além disso, o Azure AD B2C era a sepal plataforma de identidade da Microsoft. Então, se você já tinha o Microsoft 365 ou o Azure ID para seus funcionários, o B2C parecia aprender um produto completamente novo. Como esperado, as equipes de TI lutavam para mantê-lo, os dedestavam trabalhar com ele e os clientes acabavam com uma experiência de cadastro desajeitada que os fazia querer sair. A Microsoft percebeu que precisava de algo mais simples e unificado e foi exatamente isso que se tornou o Microsoft Entra External ID. O que o Microsoft Entra External ID realmente é? Então, o que exatamente é o Microsoft Entra External ID? Aqui está a definição mais simples. É um serviço de identidade em nuvem para usuários externos, clientes, parceiros e convidados, não funcionários.

Vem-se desta forma. Imagine que sua empresa tem um prédio de escritórios. Esse é o seu trabalho. É onde seus funcionários trabalham, onde ficam suas mesas, onde seus crachás dão acesso. O Entra ID gerencia esse prédio. Agora, imagine que você está abrindo uma vitrinha para clientes. Um espaço separado, com sua própria entrada, suas próprias regras, sua própria segurança. Clientes não entram na sala de descanso dos funcionários. E funcionários não acessam contas de clientes por acidente. Esse é o External ID. Ele faz parte da família Microsoft Entra, mas com uma proposta diferente. Ele foi criado para a CIEM, Gerenciamento de Acesso e Identidade do Cliente, e lida com todo o ciclo de vida de um usuário externo. Cadastro, login, redefinição de senha, gerenciamento de perfil, MFA, emissão de tokens. Funciona com protocolos padrão como OFF 2.0, OpenID Connect e CMR. Então, quase qualquer aplicativo que você criar pode se conectar.

Mas, aqui está a grande diferença do antigo Azure AD B2C. O external ID é mais simples. Chega de políticas XML personalizadas. Em vez disso, você configura fluxos de usuário diretamente no centro administrativo. Ou você usa extensões de autenticação personalizadas, que se conectam à sua lógica de back-end existente. Mesmo poder, menos dor de cabeça. De três casos de uso principal. Então, como você usa o External ID na prática? Existem três cenários principais. Eles cobrem quase todas as situações em que você precisa gerenciar alguém que não é um funcionário. Comece pelo mais comum. Identidade do cliente, ou B2C. Imagine que você está criando um aplicativo de pedidos de pizza. Você precisa que as pessoas se cadastrem, façam pedidos e voltem na próxima semana. Você quer que eles façam login com a conta do Google, em vez de criar outra senha. E você precisa coletar o nome, número de telefone e preferências de entrega.

O external ID lida com tudo isso. Você obtém fluxo de cadastro e login pré-configurado. Você configura quais atributos coletar. Nome, telefone, o que for necessário. Você configura login social com o Google, Facebook ou Apple. E quando o usuário se autentica, o external ID emite um token para o seu aplicativo para que ele saiba quem é aquela pessoa. Este é o substituto para o Azure ID B2C. E é por onde a maioria das organizações começam. Outro cenário é a colaboração entre empresas, ou B2B. É quando você precisar a parceiros ou fornecedores acesso aos seus aplicativos internos. Talvez você tenha um site no SharePoint que seu parceiro de logística externa precise ver, ou uma ferramenta. Gestão de projetos que seus designers freelancers usam. Neste cenário, você os convida como usuários convidados em seu locatário de força de trabalho. O external ID lida com o e-mail de convite e o processo de resgate onde eles aceitam o convite e as políticas de acesso que controlam que eles podem ver.

Isso, na verdade, já existe há anos como colaboração B2B dentro do Azure ID. Mas agora faz parte do guarda-chuva de ID externo, então você o gerencia do mesmo lugar que as identidades dos seus clientes. Depois, há o machine-to-machine e o M2M. Este é menos visível para os usuários finais, mas igualmente importante. Às vezes, seu serviço de back-end precisa se comunicar com outra API, um processador de pagamentos, um serviço de análise de dados ou micro-serviço interno. Não há envolvimento humano, é apenas uma aplicação chamando outra. O ID externo usa o fluxo de credenciais de cliente do Office 2.0. Seu serviço se autentica usando um ID de cliente e um segredo, e obtém um token para chamar a API de destino. Isso requer o complemento premium de M2M, então há um custo, mas se você precisa proteger a comunicação entre APIs, ele já vem integrado. Bem, esses três cenários cobrem quase todas as situações de identidade externa que você encontrará.

Mas há uma grande decisão que você precisa tomar, e é onde esses usuários realmente residem. Porque o ID externo pode operar em dois lugares muito diferentes. Tenant de força de trabalho ou tenant externo. Vamos analisar as duas opções. O ID externo pode rodar dentro do seu tenant de força de trabalho existente ou pode rodar com um tenant externo completamente separado. Eles não são a mesma coisa? Escolher o errado pode causar problemas no futuro. Comecemos pela opção de trabalho. Sua empresa já possui um tenante do Entredi para seus funcionários. Esse é o seu tenante de força de trabalho. Se você ativar um recurso chamado inscrição self-service de convidado nesse tenant, usuários externos podem se inscrever e cair no mesmo diretório dos seus funcionários. As contas deles ficam bem ao lado da conta do seu CEO. Para cenários B2B mais simples, como convidar alguns parceiros para um site do SharePoint e misturá-los no mesmo diretório perfeitamente aceitável, é simples de configurar e você não precisa gerenciar um tenant separado.

Mas questão pô. Se você está criando um aplicativo voltado para o cliente com milhares de usuários, você não quer que esses clientes fiquem no mesmo diretório que seus funcionários. Isso é um risco de segurança. Um funcionário poderia acidentalmente encontrar dados de clientes. Uma mudança de configuração destinada aos funcionários poderia afetar o acesso do cliente. E a identidade visual das páginas de login dos clientes estaria vinculada ao que você definiu para a sua empresa. Isso é um ideal. A alternativa é a opção de tenante externo. Você cria um novo diretório isolado especificamente para as identidades dos clientes. Nenhum funcionário reside aqui. É um espaço completamente separado. Lembra da analogia do prédio comercial de antes? Tenant de força e trabalho é a sua sede corporativa. O tenante externo é a vitrine dedicada que você abre para seus clientes. Eles têm sua própria entrada, suas próprias regras e sua própria segurança.

Nada se mistura. Então, quais são os benefícios de um tenante externo? Primeiro, você obtém um armazenamento de isolado. Os dados dos clientes permanecem totalmente separados dos funcionários, o que reduz riscos e simplifica a conformidade. Segundo, você tem a identidade visual separada. Você pode personalizar a aparência das páginas de login especificamente para seus clientes sem afetar nada em seu tenão corporativo. Terceiro, você obtém a API de autenticação nativa para aplicativos móveis, que permite criar telas de login totalmente personalizadas no seu app OS ou Android, sem redirecionamento de navegador, sem webvis ajeitado. E quarto, você obtém preços baseados em mal, usuários ativos mensais. Você paga apenas pelos usuários que realmente se autenticam em um determinado mês, o que escala naturalmente com o crescimento de seus clientes. Então, quando escolher qual opção? É bem simples.

Se você está criando um aplicativo B2C com milhares de clientes, escolha um tenante externo. Essa é a abordagem recomendada. E é para isso que o ExternoID foi projetado. Se você está apenas convidando parceiros para acessar recursos internos, a opção de tenante força de trabalho é suficiente. O segredo é entender a diferença antes de começar a desenvolver, pois migrar de um para o outro mais tarde não é trivial. Segurança, MFA e acesso condicional. Agora, vamos falar sobre segurança. Se você vai permitir que clientes entrem em seu aplicativo, precisa garantir que as pessoas erradas não tenham acesso. O ExternoID inclui os mesmos recursos de segurança de nível empresarial que o EntraID oferece para funcionários. Isso significa autenticação multifator, acesso condicional e políticas baseadas em risco. Para o MFA, você tem duas opções no momento. O código de acesso único por e-mail é gratuito.

Eu, o sistema, envio um código para o e-mail do usuário e ele digita o código IPROM. O código de acesso único por SMS funciona da mesma forma, mas vai para o celular com custo de operador envolvido. Uma observação importante, ainda não há suporte para o Microsoft Authentic Kit. Essa é uma limitação atual e algo em que a Microsoft provavelmente está trabalhando, mas por enquanto é e-mail ou SMS. Acesso condicional é onde as coisas ficam interessantes. Você pode definir regras que exigem, por exemplo, MFA quando o login for de risco médio ou superior ou bloquear o acesso de países onde não atuamos. O sistema avalia cada tentativa de login em tempo real. Se alguém tentar entrar de um local ou dispositivo suspeito, ele pode aumentar automaticamente os requisitos de segurança sem que você precise criar essa lógica. Mas há um recurso que realmente se destaca. Autenticação de reforço. Veja como funciona.

Imagine que um usuário entra no seu aplicativo apenas com uma senha para navegar pelo seu catálogo de produtos. Isso é aceitável para atividades de baixo risco, mas quando eles tentam ver o histórico de pagamentos ou baixar uma fatura, você deseja uma verificação adicional. Com a autenticação de elevação ou step-up, você pode exigir MFA apenas para as seções específicas do seu aplicativo. O usuário não é solicitado até que tente acessar algo sensível. Tudo é gerenciado pelo external ID nos bastidores usando algo chamado contexto de autenticação. Você define quais partes do seu app precisam de segurança extra e o sistema cuida do restante. O usuário tem uma experiência fluida na navegação básica, mas os dados sensíveis permanecem protegidos. Identidade visual e experiência do usuário. O controle de marca é um dos maiores motivos pelos quais as organizações escolhem o external ID em vez de criar seu próprio sistema de login.

Você tem controle total sobre o visual das páginas de inscrição e login, pode enviar seu logotipo, definir cores de fundo, adicionar um favicon para a aba do navegador e personalizar o cabeçalho e o rodapé com links para sua política de privacidade e termos de serviço. Se quiser ainda mais controle, você pode enviar um arquivo CSS personalizado para sobrescrever fontes, cores de botões e layout. É a sua marca, as suas cores, tudo como você decidir. Agora, é aqui que as coisas ficam um pouco complicadas. A identidade visual global pelo catar e tenant, e não por aplicativo. Portanto, se você tiver vários apps, com um portal do cliente e um app móvel, todos compartilham as mesmas páginas com a mesma identidade. Você não pode dar cada aplicativo uma aparência própria. O antigo Azure AD B2C permitia branding por aplicativo, mas o External ID ainda não oferece suporte a isso. Outra limitação, as mensagens de erro nas páginas de login não são personalizadas.

Se alguém digitar um e-mail que não existe, verá algo como Não conseguimos encontrar uma conta com esse endereço de e-mail. E você não pode alterar esse texto. Para algumas organizações, isso é aceitável, mas para outras, especialmente as em setores regulamentados, ou com um tom de voz de marca rígido, é um problema real. Aplicativos móveis são melhor. O External ID possui uma API de autenticação nativa para iOS e Android. Em vez de redirecionar usuários para uma página de login no navegador, você pode criar telas de login totalmente personalizadas dentro do seu app. Sem redirecionamento de navegador ou sem WebViews Lent, o usuário permanece no seu app o tempo todo e você controla cada pixel. É uma experiência muito mais fluida e um daqueles recursos que o Azure AD B2C nunca teve. Migração do Azure AD B2C Se você já está no Azure AD B2C, provavelmente está se perguntando o que isso significa para você.

É o seguinte, a Microsoft continuará oferecendo suporte ao B2C até pelo menos 2000. Portanto, seus locatários existentes não deixarão de funcionar amanhã, mas não haverá novos recursos. Toda a inovação, chaves de acesso, pesquisa, autenticação nativa e proteção contra fraude são exclusivas do External ID. Você está em uma plataforma que está essencialmente um índice. A Microsoft publicou ferramentas e orientações oficiais de migração. E existem dois caminhos dependendo da sua escala. Para locatários com menos de cerca de 5 milhões de objetos de diretório, usuários, grupos e atributos personalizados, a migração padrão é relativamente direta. Funciona como uma mudança de locatário para locatário. Você cria um novo locatário de ID externo, migra seus usuários e suas credenciais e depois migra seus aplicativos. A Microsoft fornece ferramentas para exportação e importação em massa de usuários.

Você pode usar a migração de senhas just-in-time para reduzir a interrupção durante a transição. Para locatários maiores, com mais de 5 milhões de objetos de diretório, existe um modo de compatibilidade de alta escala, ou HSC. Nesse modo, o ASIO AD, B2C e o ID externo funcionam lado a lado, no mesmo locatário. Seus pontos de extremidade B2C existentes permanecem ativos enquanto você move os aplicativos gradualmente. Ele foi projetado por organizações que não podem migrar milhões de usuários da noite para o dia, mas traz concessões sem provedores de identidade social, sem pass-case, acesso condicional limitado e alguns recursos simplesmente não estão disponíveis. Pense nisso como uma estratégia de transição, não como uma solução permanente. Agora uma mudança importante. As políticas personalizadas. Se você criou o fluxo de autenticação complexo usando a estrutura de experiência e identidade baseada em XML2 para a AD B2C, eles não funcionarão no ID externo, eles não funcionam no externo.

Você terá que reconstruir essa lógica usando fluxos de usuários e extensões de autenticação personalizadas. Não existe uma ferramenta mágica que converte a seu XML para o novo formar. Você simplesmente terá que fazer o trabalho. Então aqui está o resumo da situação. Se você está começando do zero hoje, use o ID externo. Não há motivo nem para considerar o B2C. Se você tem um locatário B2C existente, comece a planejar sua migração agora. Você tem até 2030, mas esperar até o último minuto significa que você terá que correr em uma migração complexa enquanto tenta manter os aplicativos atuais funcionando. Mas pequeno. Escolha um aplicativo, migre o teste e aprenda com o processo e depois faça o restante. Experiência do desenvolvedor e automação. A Microsoft focou muito em tornar o ID externo fácil para desenvolvedores e é uma grande mudança em relação às antigas políticas personalizadas do B2C.

Sabe aqueles arquivos XML que se estendiam por centenas de linhas e quebravam se esquecesse um único colchete? Isso acabou. Existe uma extensão do Visual Studio Code chamada Microsoft Entra Externoid. Após se autenticar, você pode navegar pelo seu locatário, visualizar fluxos de usuário, baixá-los como arquivos JSON e até visualizar sua marca, tudo sem sair do seu editor. Você vê como sua página de login fica antes mesmo de publicá-la. Depois, a API do Microsoft Graph. Quase todos os recursos do ID externo, fluxo de usuário, registro de aplicativos e identidade visual podem ser gerenciados programaticamente. Isso significa que você pode automatizar a configuração do locatário em seus pipelines de CICD usando PowerShell chamadas REST. Crie um novo locatário, configura os fluxos de usuário, registra o aplicativo e define a identidade visual toda a partir do script. Se você gerencia vários ambientes, isso economiza muito tempo.

As extensões de autenticação personalizadas são onde reside o verdadeiro. Em vez de CIML complexo, você estende fluxos de autenticação com chamadas HTTP simples para o Azure Functions. Existem quatro eventos nos quais você conectar. O início da emissão de token permite adicionar declarações personalizadas aos tokens como funções ou informações de nível de fidelidade. O início e o envio da coleta de atributos permitem validar ou preencher previamente os dados de inscrição chamando seu próprio back-end. E o envio de OTP por e-mail permite que você personalize os e-mails de verificação. É a mesma flexibilidade que o B2C tinha, mas em um modelo com o qual qualquer desenvolvedor pode trabalhar. Existem limitações que você deve conhecer. Ainda não há notificações do Microsoft Graph, então você não pode disparar automaticamente um fluxo de trabalho quando um novo usuário se inscreve. Algumas configurações ainda precisam ser feitas manualmente no centro e não há uma página de edição de perfil integrado.

Se você quiser que os usuários atualizem suas informações, precisa criar essa página no seu aplicativo e chamar a API do Graph Conta Pro. A seleção é clara. A Microsoft quer que o ID externo seja totalmente automatizável. Isso torna o gerenciamento em escala mais fácil. Agora você sabe. O Microsoft Enter External ID é o substituto moderno do Azure e de B2C unificado sob a marca Entra. Os três casos de uso de identidade de cliente, colaboração com parceiros e máquina a máquina cobrem quase todas as necessidades de identidade externa que você encontrará. E a decisão principal é se você deve usar seu locatário de força de trabalho ou criar um locatário externo separado. Para aplicativos voltados ao cliente, separar é quase sempre melhor. A identidade é a porta de entrada para o seu aplicativo. Tornando-a segura, personalizada e simples, impacta diretamente a confiança do usuário e o crescimento do negócio.

E o crescimento do negócio. Sua lição de casa. Vá até Entra.Microsoft.com, crie um locatário externo e experimente o guia de introdução. Ele guiará você pela configuração de um aplicativo de exemplo em Poxmon. Inscreva-se para mais explicações simples sobre a plataforma de identidade da Microsoft.