Modelo de identidade
Os Serviços de Comunicação do Azure são um serviço independente de identidade, que oferece vários benefícios:
- Reutilize identidades existentes do seu sistema de gerenciamento de identidades e mapeie-as 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.
O modelo de identidade dos Serviços de Comunicação do Azure funciona com dois conceitos principais.
Identidade do usuário / mapeamento
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. Identificadores externos, como números de telefone, IDs de usuário/dispositivo/aplicativo ou nomes de usuário, não podem ser usados 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. A criação de identidades de usuário do Serviço de Comunicação do Azure é gratuita e as cobranças só são incorridas quando o usuário consome modalidades de comunicação, como um bate-papo 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. Um usuário 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.
Tokens de acesso
Depois que uma identidade de usuário é criada, um usuário precisa de um token de acesso com escopos específicos para participar de comunicações usando chat ou chamadas. Por exemplo, apenas um usuário com um token com o escopo pode participar do bate-papo chat e um usuário com um token com 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 contabilizar usuários que precisam de acesso total versus acesso limitado. Os tokens de acesso têm as seguintes propriedades.
| Property | Description |
|---|---|
| Assunto | A identidade do usuário que é representada pelo token. |
| Expiração | 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 vitalícios curtos para reuniões pontuais e tokens vitalícios mais longos para usuários que usam seu aplicativo por períodos de tempo mais longos. |
| Âmbitos | Os escopos definem quais primitivos de comunicação (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
Três escopos de token de chat diferentes são suportados. As permissões para cada escopo são descritas na tabela a seguir.
chatchat.joinchat.join.limited
| Capacidade / Escopo do token | chat | bate-papo.junte-se | chat.join.limited |
|---|---|---|---|
| Criar thread de bate-papo | Y | N | N |
| Atualizar thread de bate-papo com ID | Y | N | N |
| Excluir thread de bate-papo com 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 de thread | Y | Y | Y |
Escopos de token VoIP
Dois escopos de token VoIP são suportados. As permissões para cada escopo são descritas na tabela a seguir.
voipvoip.join
| Capacidade / Escopo do token | VoIP | voip.junte-se |
|---|---|---|
| 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, etc. | Y | Y |
| Todas as outras operações em chamada, como silenciar/desativar o som, compartilhamento de tela, etc. 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 onde apenas os usuários convidados obtêm acesso e onde 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. Consequentemente, todas as identidades perdem acesso aos Serviços de Comunicação do Azure e precisam de novos tokens de acesso.
Arquitetura cliente-servidor
Você deve criar e gerenciar tokens de acesso de usuário por meio de um serviço confiável e não criar tokens em seu aplicativo cliente. A cadeia de conexão ou as credenciais do Microsoft Entra que são necessárias para criar tokens de acesso do usuário precisam ser protegidas, 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 distribuídos livremente e são 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.
Próximos passos
- Para saber como emitir tokens, consulte Criar e gerenciar tokens de acesso.
- Para obter uma introdução à autenticação, consulte Autenticar nos Serviços de Comunicação do Azure.
- Para ler sobre residência e privacidade de dados, consulte Disponibilidade de região e residência de dados.
- Para saber como criar rapidamente identidades e tokens para teste, consulte o Guia de início rápido de identidade de criação rápida.
- Para obter uma amostra completa de um serviço de gerenciamento de identidade simples, visite o tutorial 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, vá para Exemplo de herói do serviço de autenticação.