Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Os Serviços de Comunicação do Azure são um serviço independente de identidade, que oferece vários benefícios:
- Reutilize as identidades existentes do sistema de gerenciamento de identidades e mapeie-as com as identidades dos Serviços de Comunicação do Azure.
- Funciona bem com qualquer sistema de identidade existente e não tem dependência em um provedor de identidade específico.
- Mantenha os dados do usuário, como seu nome, privados, pois você não precisa duplicá-los nos Serviços de Comunicação do Azure.
O modelo de identidade dos Serviços de Comunicação do Azure funciona com dois conceitos principais.
Identidade/mapeamento do usuário
Ao criar 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 usuário consome serviços de comunicação, como um chat ou uma chamada. A forma como você usa a identidade dos Serviços de Comunicação gerada depende do seu cenário. Por exemplo, você poderá mapear uma identidade 1:1, 1:N, N:1 ou N:N e usá-la para usuários ou aplicativos humanos. O 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 é interno. Por exemplo, adicione uma coluna CommunicationServicesId 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 na arquitetura cliente-servidor.
(Versão prévia) Simplificar o mapeamento de identidade com customId
Importante
Esse recurso está disponível a partir da versão 1.4.0-beta1 do SDK de Identidade e da versão 2025-03-02-previewda API REST.
Observação
Esse recurso está atualmente em versão prévia.
Anteriormente, os desenvolvedores eram responsáveis por manter um mapeamento entre seu próprio sistema de identidade de usuário e identidades dos Serviços de Comunicação do Azure. Com a introdução do customId parâmetro, agora você pode associar seus próprios identificadores de usuário, como endereços de email ou IDs de usuário internas, diretamente ao criar uma identidade dos 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 tem suporte 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, somente um usuário com um token de escopo de chat pode participar do chat. Somente um usuário com um token de voip escopo pode participar de uma 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 considerar os usuários que exigem acesso total versus acesso limitado. Os tokens de acesso têm as propriedades a seguir.
| Propriedade | Descrição |
|---|---|
| Assunto | A identidade do usuário representada pelo token. |
| Expiração | Um token de acesso é válido por pelo menos 1 hora e até 24 horas. Após expirar, o token de acesso fica 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. É recomendável usar tokens de tempo de vida curto para reuniões individuais e tokens de tempo de vida mais longos para usuários que precisam de seu aplicativo por períodos mais longos de tempo. |
| Escopos | Os escopos definem quais serviços (Chat/VoIP) podem ser acessados com o token. |
Um token de acesso é um JWT (Token Web JSON) e tem proteção de integridade. Ou seja, suas declarações não podem ser alteradas sem invalidar o token de acesso porque a assinatura do token não corresponde mais. Se os 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 de token ou de suas declarações. O formato do token pode ser alterado e não faz parte do contrato oficial de API. Os Serviços de Comunicação do Azure dão suporte aos escopos para tokens de acesso a seguir.
Escopos de token de chat
O modelo de identidade dá suporte a 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
| Escopo de funcionalidade/token | chat |
chat.join |
chat.join.limited |
|---|---|---|---|
| Criar a conversa de chat | S | N | N |
| Atualizar o thread de chat com a ID | S | N | N |
| Excluir thread de chat com a ID | S | N | N |
| Adicionar participante a uma conversa de chat | S | S | N |
| Remover participante de uma conversa de chat | S | S | N |
| Obter conversas de chat | S | S | S |
| Obter conversa de chat com a ID | S | S | S |
| Obter ReadReceipt | S | S | S |
| Criar ReadReceipt | S | S | S |
| Criar mensagem para conversa de chat com a ID | S | S | S |
| Obter mensagem com a ID da mensagem | S | S | S |
| Atualizar sua própria mensagem com a ID da mensagem | S | S | S |
| Excluir sua própria mensagem com a ID da mensagem | S | S | S |
| Enviar indicador de digitação | S | S | S |
| Obter participante para a ID da conversa | S | S | S |
Escopos de token VoIP
O modelo de identidade dá suporte a dois escopos de token VoIP. As permissões para cada escopo são descritas na tabela a seguir.
voipvoip.join
| Escopo de funcionalidade/token | voip |
voip.join |
|---|---|---|
| Iniciar uma chamada VoIP | S | N |
| Inicie uma chamada VoIP em Virtual Rooms, quando o usuário já estiver convidado para a Sala | S | S |
| Ingressar em uma chamada VoIP InProgress | S | S |
| Ingressar em uma chamada VoIP InProgress no Virtual Rooms, quando o usuário já estiver convidado para a Sala | S | S |
| Todas as outras operações durante a chamada, como silenciar/ativar som, compartilhamento de tela e assim por diante | S | S |
| Todas as outras operações de chamada, como ativar/desativar som, compartilhamento de tela e assim por diante, em Salas Virtuais. | Determinado pela função de usuário | Determinado pela função de usuário |
Você pode usar o escopo voip.join junto com Salas para criar uma chamada agendada. Nesse cenário, somente usuários convidados têm acesso e os usuários são proibidos de criar outras chamadas.
Revogar ou atualizar o 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 do seu tempo de expiração. A revogação de token não é imediata. Pode levar até 15 minutos para propagar.
- Excluir uma identidade, recurso ou assinatura revoga todos os tokens de acesso.
- Se você quiser remover a capacidade do usuário de acessar a funcionalidade específica, revogue todos os tokens de acesso do usuário. Em seguida, emita um 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 tecla de acesso anterior. Portanto, todas as identidades perdem o acesso aos Serviços de Comunicação do Azure e precisam de novos tokens de acesso.
Arquitetura do servidor-cliente
Crie e gerencie tokens de acesso do 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 do usuário. Lembre-se de proteger as credenciais, passá-las para um cliente correria o risco de vazar o segredo. A falha ao gerenciar corretamente tokens de acesso pode resultar em encargos extras em seu recurso quando os tokens são dispensados livremente e mal utilizados por outra pessoa.
Caso armazene em cache tokens de acesso a um repositório de backup, recomendamos criptografar os tokens. Um token de acesso fornece acesso a dados confidenciais e pode ser usado para atividades mal-intencionadas se não estiver protegido. Qualquer pessoa com o token de acesso de um usuário pode acessar os dados de chat desse usuário ou participar de chamadas representando o usuário.
Inclua somente os escopos no token de que seu aplicativo cliente precisa para seguir o princípio de segurança de privilégios mínimos.
- Um usuário inicia o aplicativo cliente.
- O aplicativo cliente entra em contato com seu serviço de gerenciamento de identidades.
- O serviço de gerenciamento de identidade autentica o usuário do aplicativo. É possível 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 atenuar o abuso de token.
- Criar ou localizar 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 do aplicativo 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 identidade emite um token de acesso do 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 identidades. Esses serviços são dimensionados facilmente e têm recursos internos para autenticar usuários. Eles são integrados ao OpenID e provedores de identidade de terceiros, como o Facebook.
Próximas etapas
- Para emitir tokens, consulte Criar e gerenciar tokens de acesso para usuários finais.
- Para obter uma introdução à autenticação, confira Autenticar para os Serviços de Comunicação do Azure.
- Para se informar sobre a privacidade e a residência de dados, confira Disponibilidade de região e residência de dados.
- Para obter um exemplo completo de um serviço de gerenciamento de identidade simples, consulte o 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 o exemplo principal do serviço de Autenticação.