Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Os Serviços de Comunicação do Azure são um serviço independente de identidade, que oferece vários benefícios:
- Adote um modelo BYOI (traga sua própria identidade), permitindo que você reutilize identidades existentes do seu sistema de gerenciamento de identidades e as mapeie com identidades dos Serviços de Comunicação do Azure.
- Funciona bem com qualquer sistema de identidade existente e não depende de um provedor de identidade específico.
- Mantenha os dados do usuário, como o nome dele, privados, pois você não precisa duplicá-los nos Serviços de Comunicação do Azure.
- As organizações que usam o Microsoft Entra ID para gerenciamento de identidade e acesso agora podem acessar os recursos dos Serviços de Comunicação do Azure diretamente com os usuários do Entra ID. Este novo suporte para autenticação Entra ID elimina a necessidade de desenvolver ou operar seu próprio serviço de proxy de autorização ou gerenciamento de identidade. Este recurso está atualmente em pré-visualização pública.
O modelo de identidade dos Serviços de Comunicação do Azure funciona com dois conceitos principais.
Traga sua própria identidade (BYOI): Integração com seu sistema de gerenciamento de identidade
Os Serviços de Comunicação do Azure dão suporte a um modelo BYOI (traga sua própria identidade), que permite a integração com seu sistema de gerenciamento de identidade existente. Você pode criar identidades de usuário nos Serviços de Comunicação do Azure e mapeá-las para seu próprio sistema de identidade de usuário. Essa abordagem permite gerenciar identidades de usuário e tokens de acesso sem duplicar dados do usuário nos Serviços de Comunicação do Azure.
As seções a seguir irão guiá-lo através dos conceitos-chave do modelo bring your own identity (BYOI):
- Como mapear identidades de usuário: mapeamento de identidade de usuário no modelo traga sua própria identidade (BYOI).
- Como criar e gerenciar tokens de acesso: Tokens de acesso.
- Como implementar uma arquitetura cliente-servidor para seu gerenciamento de identidade: Arquitetura cliente-servidor para o modelo bring your own identity (BYOI).
Mapeamento de identidade do usuário no modelo bring your own identity (BYOI)
Quando você cria uma identidade de usuário por meio do SDK ou da API REST, os Serviços de Comunicação do Azure criam um identificador de usuário exclusivo. Você não pode usar identificadores externos, como números de telefone, IDs de usuário/dispositivo/aplicativo ou nomes de usuário diretamente nos Serviços de Comunicação do Azure. Em vez disso, você precisa usar as identidades dos Serviços de Comunicação e manter um mapeamento para seu próprio sistema de ID de usuário, conforme necessário.
Você pode criar identidades de usuário do Serviço de Comunicação do Azure gratuitamente. Os únicos encargos são incorridos quando o utilizador consome serviços de comunicação, como um chat ou uma chamada. A forma como utiliza a identidade dos Serviços de Comunicação gerada depende do cenário. Por exemplo, você pode mapear uma identidade 1:1, 1:N, N:1 ou N:N e pode usá-la para usuários humanos ou aplicativos. Seu usuário final pode participar de várias sessões de comunicação, usando vários dispositivos, simultaneamente.
Gerenciar um mapeamento entre as identidades de usuário dos Serviços de Comunicação do Azure e seu próprio sistema de identidade é sua responsabilidade como desenvolvedor e não vem interno. Por exemplo, você pode adicionar uma CommunicationServicesId coluna em sua tabela de usuário existente para armazenar a identidade associada dos Serviços de Comunicação do Azure. Um design de mapeamento é descrito com mais detalhes em Arquitetura cliente-servidor para o modelo bring your own identity (BYOI).
(Pré-visualização) Simplifique o mapeamento de identidade com customId
Important
Esse recurso está disponível a partir da versão 1.4.0-beta1 do SDK do Identity e da versão 2025-03-02-previewda API REST.
Note
Esta funcionalidade está atualmente em pré-visualização.
Anteriormente, os desenvolvedores eram responsáveis por manter um mapeamento entre seu próprio sistema de identidade de usuário e as identidades dos Serviços de Comunicação do Azure. Com a introdução do parâmetro customId, agora é possível associar diretamente os seus próprios identificadores de utilizador—como endereços de e-mail ou IDs de utilizador internos—quando cria uma identidade de Serviços de Comunicação.
Quando você cria um usuário com um customId, os Serviços de Comunicação do Azure retornarão a mesma identidade se você chamar o método novamente com o mesmo customId. Isso elimina a necessidade de armazenar e gerenciar o mapeamento por conta própria.
Esse recurso é suportado no SDK e na API REST e é especialmente útil para cenários em que você deseja manter uma identidade consistente entre sessões, dispositivos ou serviços sem sobrecarga de armazenamento adicional.
Tokens de acesso
Depois de criar uma identidade de usuário, o usuário final precisa de um token de acesso com escopos específicos para participar de comunicações usando chat ou chamadas. Por exemplo, apenas um utilizador com um token de chat escopo pode participar no bate-papo. Apenas um utilizador com um token de voip escopo pode participar numa chamada VoIP.
Um usuário pode ter vários tokens simultaneamente. Os Serviços de Comunicação do Azure dão suporte a vários escopos de token para contabilizar usuários que precisam de acesso total versus acesso limitado. Os tokens de acesso têm as seguintes propriedades.
| Property | Description |
|---|---|
| Subject | A identidade do usuário representada pelo token. |
| Expiration | Um token de acesso é válido por pelo menos 1 hora e até 24 horas. Depois de expirar, o token de acesso é inválido e não pode ser usado para acessar o serviço. Para criar um token com um tempo de expiração personalizado, especifique a validade desejada em minutos (>=60, <1440). Por padrão, o token é válido por 24 horas. Recomendamos o uso de tokens de vida curta para reuniões individuais e tokens de vida mais longa para usuários que precisam de seu aplicativo por períodos de tempo mais longos. |
| Scopes | Os escopos definem quais serviços (Chat/VoIP) podem ser acessados com o token. |
Um token de acesso é um JSON Web Token (JWT) e tem proteção de integridade. Ou seja, suas declarações não podem ser alteradas sem invalidar o token de acesso porque, então, a assinatura do token não corresponde mais. Se primitivos de comunicação forem usados com tokens inválidos, o acesso será negado. Mesmo que os tokens não sejam criptografados ou ofuscados, seu aplicativo não deve depender do formato do token ou de suas declarações. O formato do token pode mudar e não faz parte do contrato oficial da API. Os Serviços de Comunicação do Azure dão suporte aos seguintes escopos para tokens de acesso.
Escopos de token de chat
O modelo de identidade suporta três escopos de token de chat diferentes. As permissões para cada escopo são descritas na tabela a seguir.
chatchat.joinchat.join.limited
| Capacidade / Escopo do token | chat |
chat.join |
chat.join.limited |
|---|---|---|---|
| Criar thread de bate-papo | Y | N | N |
| Atualizar cadeia de bate-papo com ID | Y | N | N |
| Excluir conversa com o ID | Y | N | N |
| Adicionar participante a um tópico de chat | Y | Y | N |
| Remover participante de um tópico de chat | Y | Y | N |
| Obter tópicos de bate-papo | Y | Y | Y |
| Obter thread de bate-papo com ID | Y | Y | Y |
| Obter ReadReceipt | Y | Y | Y |
| Criar ReadReceipt | Y | Y | Y |
| Criar mensagem para thread de chat com ID | Y | Y | Y |
| Obter mensagem com ID de mensagem | Y | Y | Y |
| Atualize a sua própria mensagem com o ID da mensagem | Y | Y | Y |
| Excluir sua própria mensagem com ID de mensagem | Y | Y | Y |
| Enviar indicador de digitação | Y | Y | Y |
| Obter participante para ID da thread | Y | Y | Y |
Escopos de token VoIP
O modelo de identidade suporta dois escopos de token VoIP. As permissões para cada escopo são descritas na tabela a seguir.
voipvoip.join
| Capacidade / Escopo do token | voip |
voip.join |
|---|---|---|
| Iniciar uma chamada VoIP | Y | N |
| Iniciar uma chamada VoIP em Salas Virtuais, quando o usuário já estiver convidado para a Sala | Y | Y |
| Participar de uma chamada VoIP da InProgress | Y | Y |
| Participar de uma chamada VoIP da InProgress em Salas Virtuais, quando o usuário já estiver convidado para a Sala | Y | Y |
| Todas as outras operações em chamada, como silenciar/desativar o som, compartilhamento de tela e assim por diante | Y | Y |
| Todas as outras operações em chamada, como silenciar/desativar som, compartilhamento de tela e assim por diante, em Salas Virtuais | Determinado pela função do usuário | Determinado pela função do usuário |
Você pode usar o voip.join escopo junto com Salas para criar uma chamada agendada. Nesse cenário, apenas os usuários convidados obtêm acesso e os usuários são proibidos de criar quaisquer outras chamadas.
Revogar ou atualizar token de acesso
- A Biblioteca de Identidades dos Serviços de Comunicação do Azure pode ser usada para revogar um token de acesso antes de seu tempo de expiração. A revogação do token não é imediata. Pode levar até 15 minutos para se propagar.
- A exclusão de uma identidade, recurso ou assinatura revoga todos os tokens de acesso.
- Se você quiser remover a capacidade de um usuário acessar uma funcionalidade específica, revogue todos os tokens de acesso para o usuário. Em seguida, emita um novo token de acesso que tenha um conjunto mais limitado de escopos.
- A rotação de chaves de acesso revoga todos os tokens de acesso ativos que foram criados usando uma chave de acesso anterior. Assim, todas as identidades perdem acesso aos Serviços de Comunicação do Azure e precisam de novos tokens de acesso.
Arquitetura cliente-servidor para o modelo leve a sua própria identidade (BYOI)
Crie e gerencie tokens de acesso de usuário por meio de um serviço confiável e não crie tokens em seu aplicativo cliente. Você precisa da cadeia de conexão ou das credenciais do Microsoft Entra para criar tokens de acesso de usuário. Lembre-se de proteger as credenciais, passá-las para um cliente correria o risco de vazar o segredo. A falha em gerenciar adequadamente os tokens de acesso pode resultar em cobranças extras em seu recurso quando os tokens são dispensados livremente e usados indevidamente por outra pessoa.
Se você armazenar tokens de acesso em cache em um repositório de backup, recomendamos criptografar os tokens. Um token de acesso dá acesso a dados confidenciais e pode ser usado para atividades maliciosas se não estiver protegido. Qualquer pessoa com o token de acesso de um usuário pode acessar os dados de bate-papo desse usuário ou participar de chamadas se passando pelo usuário.
Certifique-se de incluir apenas os escopos no token de que seu aplicativo cliente precisa para seguir o princípio de segurança de menor privilégio.
- Um usuário inicia o aplicativo cliente.
- O aplicativo cliente entra em contato com seu serviço de gerenciamento de identidade.
- O serviço de gerenciamento de identidades autentica o usuário do aplicativo. Você pode ignorar a autenticação para cenários em que o usuário é anônimo, mas tenha cuidado para adicionar outras medidas de proteção, como limitação e CORS ao seu serviço para mitigar o abuso de token.
- Crie ou localize uma identidade dos Serviços de Comunicação para o usuário.
- Cenário de identidade estável: seu serviço de gerenciamento de identidades mantém um mapeamento entre identidades de aplicativo e identidades de Serviços de Comunicação. (As identidades de aplicativos incluem seus usuários e outros objetos endereçáveis, como serviços ou bots.) Se a identidade do aplicativo for nova, uma nova identidade de Comunicação será criada e um mapeamento será armazenado.
- Cenário de identidade efêmera: o serviço de gerenciamento de identidade cria uma nova identidade de comunicação. Nesse cenário, o mesmo usuário acaba com uma identidade de comunicação diferente para cada sessão.
- O serviço de gerenciamento de identidades emite um token de acesso de usuário para a identidade aplicável e o retorna ao aplicativo cliente.
O Serviço de Aplicativo do Azure ou o Azure Functions são duas alternativas para operar o serviço de gerenciamento de identidade. Esses serviços são dimensionados facilmente e têm recursos integrados para autenticar usuários. Eles são integrados com OpenID e provedores de identidade de terceiros, como o Facebook.
Microsoft Entra ID: Integração com o Entra ID
Important
Esta funcionalidade dos Serviços de Comunicação do Azure está atualmente em pré-visualização. Os recursos na visualização estão disponíveis publicamente e podem ser usados por todos os clientes novos e existentes da Microsoft.
APIs e SDKs de pré-visualização são fornecidos sem um acordo de nível de serviço. Recomendamos que você não os use para cargas de trabalho de produção. Determinadas funcionalidades podem não ser suportadas ou recursos podem ser restringidos.
Para obter mais informações, veja Termos Suplementares de Utilização para Pré-visualizações do Microsoft Azure.
Os Serviços de Comunicação do Azure agora dão suporte à autenticação do Microsoft Entra ID, permitindo que você acesse os recursos dos Serviços de Comunicação do Azure diretamente com os usuários do Entra ID. Este novo suporte para autenticação Entra ID elimina a necessidade de desenvolver ou operar seu próprio serviço de proxy de autorização ou gerenciamento de identidade mencionado na seção Arquitetura cliente-servidor.
As seções a seguir irão guiá-lo pelos aspetos essenciais da integração do Microsoft Entra ID:
- Como obter e gerenciar tokens de acesso: Tokens de acesso com ID do Microsoft Entra.
- Como implementar uma arquitetura de cliente com o Microsoft Entra ID: Arquitetura de cliente para o Microsoft Entra ID.
- Limitações Atuais e Orientações Recomendadas: Limitações.
Tokens de acesso associados ao Microsoft Entra ID
Apenas os tokens de acesso dos Serviços de Comunicação do Azure têm suporte para autenticação e autorização nos Serviços de Comunicação do Azure, incluindo funcionalidades de chat e chamada. Para obter mais informações sobre estrutura e gerenciamento de tokens, consulte Tokens de acesso. Durante a visualização pública do Microsoft Entra ID, apenas os escopos de token de acesso às chamadas (VoIP) são suportados através da integração com o Entra ID.
Com a integração do Microsoft Entra ID, você autentica usuários por meio do Entra ID, obtém um token de acesso de usuário do Entra ID com permissões de API para o aplicativo Clientes dos Serviços de Comunicação do Azure e o troca por um token de acesso dos Serviços de Comunicação do Azure. Os SDKs Comuns dos Serviços de Comunicação do Azure oferecem autenticação contínua obtendo automaticamente um token de acesso dos Serviços de Comunicação do Azure para o usuário do Entra ID. Para obter mais informações sobre como implementar a lógica com o SDK Comum dos Serviços de Comunicação do Azure, consulte Obter tokens de acesso para usuários do Microsoft Entra ID
As permissões de API para o aplicativo Clientes dos Serviços de Comunicação do Azure são nomeadas de forma consistente com os escopos de token de acesso dos Serviços de Comunicação do Azure descritos nas seções Escopos de token de chat e Escopos de token VoIP. A tabela a seguir mostra o mapeamento entre as permissões da API e os escopos do token de acesso.
Important
As permissões da API de bate-papo (mensagens) (Chat, Chat.Join, Chat.Join.Limited) ainda não são suportadas através do Microsoft Entra ID na pré-visualização pública. Por enquanto, apenas permissões relacionadas ao VoIP (VoIP, VoIP.Join) estão disponíveis. O suporte por chat está planejado para uma atualização futura.
| Permissão da API dos Clientes dos Serviços de Comunicação do Azure | Escopo do token de acesso dos Serviços de Comunicação do Azure |
|---|---|
Chat (Versão de pré-visualização pública do Entra ID: apenas VoIP – chat brevemente disponível) |
chat |
Chat.Join (Visualização pública antecipada do Entra ID: apenas VoIP – chat disponível em breve) |
chat.join |
Chat.Join.Limited (Prévia pública do Entra ID: apenas VoIP e chat em breve) |
chat.join.limited |
VoIP |
voip |
VoIP.Join |
voip.join |
Os tokens de acesso dos Serviços de Comunicação do Azure são emitidos com a mesma expiração que o token de acesso de usuário do Microsoft Entra ID.
Arquitetura de cliente para Microsoft Entra ID
Com a integração do Microsoft Entra ID, você pode simplificar sua arquitetura usando diretamente o Entra ID para autenticação e autorização. As etapas a seguir descrevem o processo:
- Um usuário inicia o aplicativo cliente.
- A aplicação cliente autentica o utilizador através do Microsoft Entra ID. O aplicativo cliente obtém um token de acesso de usuário do Entra ID com permissões de API para o aplicativo Clientes dos Serviços de Comunicação do Azure.
- O aplicativo cliente obtém um token de acesso dos Serviços de Comunicação do Azure para o usuário do Entra ID usando um dos seguintes métodos:
- Usando os SDKs Comuns dos Serviços de Comunicação do Azure: o cliente inicializa a CommunicationTokenCredential com opções de credenciais de token de ID do Entra, que manipula automaticamente a obtenção de um token de acesso dos Serviços de Comunicação do Azure para o usuário do Entra ID em segundo plano. Em seguida, o aplicativo usa essa credencial para acessar APIs dos Serviços de Comunicação do Azure.
- Implementação personalizada: o aplicativo cliente chama o token de ID do Exchange Entra para a API de token de acesso dos Serviços de Comunicação do Azure para obter um token de acesso dos Serviços de Comunicação do Azure. O token de acesso resultante dos Serviços de Comunicação do Azure é usado para acessar as APIs dos Serviços de Comunicação do Azure.
Essa arquitetura elimina a necessidade de um serviço de gerenciamento de identidade separado, já que o Microsoft Entra ID lida diretamente com a autenticação e autorização do usuário.
Limitações
A integração do Microsoft Entra ID está atualmente em pré-visualização e tem as seguintes limitações:
- A Avaliação Contínua de Acesso não está disponível. Para revogar tokens de acesso imediatamente, siga as instruções em Revogar tokens de acesso.
- A remoção de um usuário do Entra ID não remove automaticamente todos os dados associados do recurso Serviços de Comunicação. Para garantir que todos os dados sejam excluídos, siga as instruções em Excluir uma identidade.
- As permissões da API de chat (mensagens) (
Chat,Chat.JoinChat.Join.Limited, ) não podem ser concedidas ou usadas por meio da integração do Microsoft Entra ID na visualização pública. Somente permissões relacionadas a VoIP (VoIP,VoIP.Join) são suportadas. Use o modelo de identidade BYOI para obter tokens de acesso ao chat até o GA.
Próximos passos
- Para emitir tokens, consulte Criar e gerenciar tokens de acesso para usuários finais.
- Para obter uma introdução à autenticação, consulte Autenticar nos Serviços de Comunicação do Azure.
- Para obter detalhes sobre como funciona a autenticação em cenários de Microsoft Entra ID de locatário único e multilocatário, consulte Locação no Microsoft Entra ID.
- Para obter um início rápido sobre como autenticar usuários do Microsoft Entra ID, consulte Autenticar usuários do Microsoft Entra ID.
- Para ler sobre residência e privacidade de dados, consulte Disponibilidade da região e residência de dados.
- Para obter uma amostra completa de um serviço de gerenciamento de identidade simples, consulte Tutorial de serviço confiável.
- Para obter um exemplo de gerenciamento de identidade mais avançado que se integra ao Entra ID e ao Microsoft Graph, consulte Exemplo de herói do serviço de autenticação.