Compartir a través de

Protección de aplicaciones y API mediante la validación de declaraciones

La interacción con tokens es una parte fundamental de la creación de aplicaciones para autorizar a los usuarios. De acuerdo con el principio de confianza cero, para el acceso con privilegios mínimos, es esencial que las aplicaciones validen los valores de determinadas notificaciones presentes en el token de acceso al realizar la autorización.

La autorización basada en declaraciones permite a las aplicaciones asegurarse de que el token contiene los valores correctos para elementos como el arrendatario, el sujeto y el actor presentes en el token. Dicho esto, la autorización basada en notificaciones puede parecer compleja debido a los distintos métodos por utilizar y los escenarios para realizar un seguimiento. En este artículo, se pretende simplificar el proceso de autorización basada en notificaciones para que pueda asegurarse de que las aplicaciones se adhieran a los procedimientos más seguros.

Para asegurarse de que la lógica de autorización sea segura, debe validar la siguiente información en las reclamaciones:

  • Se especifica la audiencia adecuada para el token.
  • El id. de inquilino del token coincide con el id. del inquilino en el que se almacenan los datos.
  • El tema del token es adecuado.
  • El actor (aplicación cliente) está autorizado.

Nota

Los tokens de acceso solo se validan en las API web para las que fueron adquiridos por un cliente. El cliente no debe validar los tokens de acceso.

Para obtener más información sobre las reclamaciones mencionadas en este artículo, consulte Tokens de acceso de la plataforma de identidad de Microsoft.

Validación de la audiencia

La afirmación aud identifica al destinatario previsto del token. Antes de validar los reclamos, siempre debe comprobar que el valor del reclamo aud contenido en el token de acceso coincida con la API web. El valor puede depender de cómo el cliente solicitó el token. La audiencia del token de acceso depende del punto de conexión:

  • Para los tokens v2.0, la audiencia es el identificador de cliente de la API web. Es un GUID.
  • Para los tókenes v1.0, la audiencia es uno de los URI de appID declarados en la API web que valida el token. Por ejemplo, api://{ApplicationID}, o un nombre único a partir de un nombre de dominio (si el nombre de dominio está asociado a un inquilino).

Para obtener más información sobre el identificador URI de la aplicación, consulte Identificador URI de la aplicación.

Validación del inquilino

Compruebe siempre que el tid en un token coincida con el id. de inquilino usado para almacenar datos con la aplicación. Cuando se almacena información para una aplicación en el contexto de un inquilino, solo se debe tener acceso a ella más adelante en el mismo inquilino. Nunca permita que se acceda a los datos de un inquilino desde otro inquilino.

La validación del inquilino es el primer paso, pero las comprobaciones de asunto y actor descritos en este artículo siguen siendo necesarias. Si piensa autorizar a todos los usuarios de un inquilino, se recomienda agregar explícitamente estos usuarios a un grupo y autorizarlos en función del grupo. Por ejemplo, al comprobar solo el ID de inquilino y la presencia de una notificación oid, la API podría autorizar accidentalmente a todos los principales de servicio de ese inquilino además de los usuarios.

Validación del asunto

Determine si el sujeto del token, como el usuario (o la propia aplicación para un token de solo aplicación), está autorizado.

Puede comprobar si hay reclamaciones sub o oid específicas.

O bien,

Puede comprobar que el sujeto pertenece a un rol o grupo adecuado mediante las afirmaciones de roles, scp, groups, wids. Por ejemplo, use los valores de notificación inmutables tid y oid como clave combinada para los datos de la aplicación y determine si se debe conceder acceso a un usuario.

Las roles, groups o wids declaraciones también se pueden usar para determinar si el sujeto tiene autorización para realizar una operación, aunque no son una lista exhaustiva de todas las formas en que se pueden conceder permisos a un sujeto. Por ejemplo, un administrador puede tener permiso para escribir en una API, pero no un usuario normal, o el usuario puede estar en un grupo con permiso para realizar alguna acción determinada. La notificación wid representa los roles de todo el inquilino asignados a este usuario a partir de los roles presentes en los roles integrados de Microsoft Entra. Para más información, consulte Roles integrados de Microsoft Entra.

Advertencia

No use notificaciones como email, preferred_username o unique_name para almacenar o determinar si el usuario de un token de acceso debe tener acceso a los datos. Estas declaraciones no son únicas y pueden ser controladas por los administradores de inquilinos o, a veces, por los usuarios, lo que las hace inadecuadas para las decisiones de autorización. Solo se pueden usar con fines de visualización. Tampoco use la notificación upn para la autorización. Aunque el UPN es único, a menudo, cambia durante la vigencia de una entidad de seguridad de usuario, lo que hace que no sea confiable para la autorización.

Validación del actor

También se debe autorizar una aplicación cliente que actúa en nombre de un usuario (denominado actor). Use la declaración scp (ámbito) para validar que la aplicación tiene permiso para realizar una operación. Los permisos de scp deben limitarse a lo que realmente necesite el usuario y seguir los principios de privilegio mínimo.

Sin embargo, hay ocurrencias en las que scp no está presente en el token. Debe comprobar la falta de la notificación scp en los siguientes escenarios:

  • Permiso solo para aplicaciones en segundo plano o apps
  • Tokens de identificación

Para más información sobre los ámbitos y permisos, consulte Ámbitos y permisos en la Plataforma de identidad de Microsoft.

Nota

Una aplicación puede controlar tokens de solo aplicación (solicitudes de aplicaciones sin usuarios, como aplicaciones de demonio) y si desea autorizar una aplicación específica en varios inquilinos, en lugar de identificadores de entidad de servicio individuales. En ese caso, la reclamación appid (para los tokens v1.0) o la reclamación azp (para los tokens v2.0) se puede usar para la autorización del sujeto. Sin embargo, al utilizar estas afirmaciones, la aplicación debe asegurarse de que el token haya sido emitido directamente para la aplicación mediante la validación de la afirmación idtyp opcional. Solo se pueden autorizar tókenes de tipo app de esta manera, ya que los tókenes de usuario delegados pueden obtenerse por medio de entidades que no sean necesariamente la aplicación.

Pasos siguientes

  • Last updated on