Compartir vía

Modelo de identidad

Azure Communication Services es un servicio independiente de identidad, que ofrece varias ventajas:

  • Vuelva a usar las identidades existentes del sistema de administración de identidades y asígnelas con identidades de Azure Communication Services.
  • Funciona bien con cualquier sistema de identidad existente y no tiene ninguna dependencia en un proveedor de identidades específico.
  • Mantenga en privado los datos de sus usuarios, como su nombre, ya que no necesita duplicarlos en Azure Communication Services.

El modelo de identidad de Azure Communication Services funciona con dos conceptos clave.

Identidad de usuario/asignación

Al crear una identidad de usuario a través del SDK o la API REST, Azure Communication Services crea un identificador de usuario único. No puede usar identificadores externos, como números de teléfono, identificadores de usuario, dispositivo o aplicación, o nombres de usuario directamente en Azure Communication Services. En su lugar, debe usar las identidades de Servicios de Comunicación y mantener un mapeo con su propio sistema de ID de usuario según sea necesario.

Puede crear identidades de usuario de Azure Communication Service de forma gratuita. Los únicos cargos se incurren cuando el usuario consume servicios de comunicación como un chat o una llamada. La forma de usar la identidad de Communication Services generada depende de su escenario. Por ejemplo, puede asignar una identidad 1:1, 1:N, N:1 o N:N, y puede usarla para usuarios o aplicaciones humanas. El usuario final puede participar en varias sesiones de comunicación, mediante varios dispositivos, simultáneamente.

La administración de una asignación entre las identidades de usuario de Azure Communication Services y su propio sistema de identidades es su responsabilidad como desarrollador y no viene integrada. Por ejemplo, puede agregar una CommunicationServicesId columna en la tabla de usuario existente para almacenar la identidad de Azure Communication Services asociada. Un diseño de asignación se describe con más detalle en Arquitectura de cliente-servidor.

(Versión preliminar) Simplifica la asignación de identidades con customId

Importante

Esta característica está disponible a partir de la versión del SDK de Identidad 1.4.0-beta1 y de la versión 2025-03-02-preview de la API REST.

Nota:

Esta funcionalidad actualmente está en su versión preliminar.

Anteriormente, los desarrolladores eran responsables de mantener una asignación entre su propio sistema de identidad de usuario y las identidades de Azure Communication Services. Con la introducción del customId parámetro , ahora puede asociar sus propios identificadores de usuario (como direcciones de correo electrónico o identificadores de usuario internos) directamente al crear una identidad de Communication Services.

Al crear un usuario con customId, Azure Communication Services devolverá la misma identidad si vuelve a llamar al método con el mismo customId. Esto elimina la necesidad de almacenar y administrar la asignación usted mismo.

Esta característica se admite tanto en el SDK como en la API REST, y es especialmente útil para escenarios en los que desea mantener una identidad coherente entre sesiones, dispositivos o servicios sin sobrecarga de almacenamiento adicional.

Tokens de acceso

Después de crear una identidad de usuario, el usuario final necesita un token de acceso con ámbitos específicos para participar en comunicaciones mediante chat o llamadas. Por ejemplo, solo un usuario con un token de chat ámbito puede participar en el chat. Solo un usuario con un token de voip ámbito puede participar en una llamada VoIP.

Un usuario puede tener varios tokens simultáneamente. Azure Communication Services admite varios ámbitos de token para tener en cuenta a los usuarios que requieren acceso total frente al acceso limitado. Los tokens de acceso tienen las siguientes propiedades.

Propiedad Descripción
Asunto La identidad de usuario representada por el token.
Vencimiento Un token de acceso es válido durante al menos 1 hora y hasta 24 horas. Una vez expirado, el token de acceso no es válido y no se puede usar para acceder al servicio. Para crear un token con una hora de expiración personalizada, especifique la validez deseada en minutos (>=60, <1440). De forma predeterminada, el token es válido durante 24 horas. Se recomienda usar tokens de duración corta para reuniones únicas y tokens de duración más largos para los usuarios que necesitan la aplicación durante períodos de tiempo más largos.
Ámbitos Los ámbitos definen a qué servicios (Chat/VoIP) se puede acceder con el token.

Un token de acceso es un JSON Web Token (JWT) y tiene protección de integridad. Es decir, sus notificaciones no se pueden cambiar sin invalidar el token de acceso porque la firma del token ya no coincide. Si se utilizan primitivas de comunicación con tokens no válidos, se deniega el acceso. Aunque los tokens no están cifrados ni ofuscados, la aplicación no debe depender del formato del token ni de sus notificaciones. El formato del token puede cambiar y no forma parte del contrato de API oficial. Azure Communication Services admite los siguientes ámbitos para los tokens de acceso.

Ámbitos de los tokens de chat

El modelo de identidad admite tres ámbitos de token de chat diferentes. Los permisos para cada ámbito se describen en la siguiente tabla.

  • chat
  • chat.join
  • chat.join.limited
Ámbito de funcionalidad/token chat chat.join chat.join.limited
Creación de subprocesos de chat S N N
Actualización del subproceso de chat con el identificador S N N
Eliminar subproceso de chat con el identificador S N N
Agregar participante a un subproceso de chat S S N
Eliminación del participante de una conversación de chat S S N
Obtener subprocesos de chat S S S
Obtención del subproceso de chat con el identificador S S S
Obtener ReadReceipt S S S
Creación de ReadReceipt S S S
Creación de un mensaje para el subproceso de chat con identificador S S S
Obtención de un mensaje con el identificador de mensaje S S S
Actualización de su propio mensaje con el identificador de mensaje S S S
Eliminar su propio mensaje con el identificador de mensaje S S S
Envío de indicadores de escritura S S S
Obtención del participante para el identificador de subproceso S S S

Ámbitos de token de VoIP

El modelo de identidad admite dos ámbitos de token voIP. Los permisos para cada ámbito se describen en la siguiente tabla.

  • voip
  • voip.join
Ámbito de funcionalidad/token voip voip.join
Iniciar una llamada VoIP S N
Inicie una llamada VoIP en Virtual Rooms cuando el usuario ya esté invitado a la sala S S
Unirse a una llamada VoIP de InProgress S S
Únase a una llamada VoIP de InProgress en Virtual Rooms, cuando el usuario ya esté invitado a la sala S S
Todas las demás operaciones en llamada, como silenciar o desactivar, compartir pantalla, etc. S S
Todas las demás operaciones en llamada, como silenciar o desactivar, compartir pantalla, etc., en Virtual Rooms Determinado por el rol de usuario Determinado por el rol de usuario

Puede usar el voip.join ámbito junto con Salas para crear una llamada programada. En este escenario, solo los usuarios invitados obtienen acceso y los usuarios no pueden crear ninguna otra llamada.

Revocar o actualizar el token de acceso

  • La biblioteca de identidades de Azure Communication Services se puede usar para revocar un token de acceso antes de su hora de expiración. La revocación del token no es inmediata. Puede tardar hasta 15 minutos en propagarse.
  • Al eliminar una identidad, un recurso o una suscripción, se revoca todos los tokens de acceso.
  • Si desea quitar la capacidad de un usuario para acceder a una funcionalidad específica, revoque todos los tokens de acceso para el usuario. Después, emita un nuevo token de acceso que tenga un conjunto de ámbitos más limitado.
  • La rotación de claves de acceso revoca todas las fichas de acceso activas que se crearon utilizando una clave de acceso anterior. Por lo tanto, todas las identidades pierden el acceso a Azure Communication Services y necesitan nuevos tokens de acceso.

Arquitectura de cliente y servidor

Cree y administre tokens de acceso de usuario a través de un servicio de confianza y no cree tokens en la aplicación cliente. Necesita la cadena de conexión o las credenciales de Microsoft Entra para crear tokens de acceso de usuario. Recuerde proteger las credenciales y pasarlas a un cliente corre el riesgo de perder el secreto. Si no se administran correctamente los tokens de acceso, se pueden generar cargos adicionales en el recurso cuando los tokens se dispensan libremente y se usan incorrectamente por otra persona.

Si almacena en caché los tokens de acceso a un almacén de respaldo, se recomienda cifrar los tokens. Un token de acceso da acceso a datos sensibles y puede utilizarse para actividades maliciosas si no está protegido. Cualquier persona con el token de acceso de un usuario puede acceder a los datos de chat del usuario o participar en llamadas que suplantan al usuario.

Asegúrese de incluir solo esos ámbitos en el token que la aplicación cliente necesita para seguir el principio de seguridad de privilegios mínimos.

Diagrama que muestra la arquitectura de tokens de acceso al usuario.

  1. Un usuario inicia la aplicación cliente.
  2. La aplicación cliente se pone en contacto con el servicio de administración de identidades.
  3. El servicio de administración de identidades autentica al usuario de la aplicación. Puede omitir la autenticación para escenarios en los que el usuario es anónimo, pero tenga cuidado de añadir otras medidas de protección como la limitación y CORS a su servicio para mitigar el abuso de tokens.
  4. Cree o busque una identidad de Communication Services para el usuario.
    1. Escenario de identidad estable: su servicio de administración de identidades mantiene una correspondencia entre las identidades de las aplicaciones y las identidades de Communication Services. (Las identidades de aplicación incluyen a los usuarios y otros objetos direccionables, como servicios o bots). Si la identidad de la aplicación es nueva, se crea una nueva identidad de Comunicación y se almacena una asignación.
    2. Escenario de identidad efímero: el servicio de administración de identidades crea una nueva identidad de comunicación. En este escenario, el mismo usuario termina con una identidad de comunicación diferente para cada sesión.
  5. El servicio de administración de identidades emite un token de acceso de usuario para la identidad aplicable y lo devuelve a la aplicación cliente.

Azure App Service o Azure Functions son dos alternativas para operar el servicio de administración de identidades. Estos servicios se escalan fácilmente y tienen características integradas para autenticar a los usuarios. Se integran con OpenID y proveedores de identidades de terceros como Facebook.

Pasos siguientes