Partekatu honen bidez:

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

  • Artikulua

Interactuar con tókenes 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 notificaciones permite a las aplicaciones asegurarse de que el token contiene los valores correctos para elementos como el inquilino, el asunto 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 notificaciones:

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

Nota

Los tókenes de acceso solo se validan en las API web que el cliente ha adquirido con ese fin. El cliente no debe validar los tókenes de acceso.

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

Validación de la audiencia

La notificación aud identifica la audiencia prevista del token. Antes de validar las notificaciones, siempre debe comprobar que el valor de la notificación aud contenida 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 tókenes 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 appID de una aplicación, consulte Identificador URI de id. de 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 suscriptor es solo el primer paso y las comprobaciones sobre el asunto y el actor descritos en este artículo siguen siendo necesarias. Si su intención es autorizar a todos los usuarios de un suscriptor, se recomienda encarecidamente agregar explícitamente estos usuarios a un grupo y autorizar en función del grupo. Por ejemplo, al comprobar solo el id. de suscriptor y la presencia de una notificación oid, la API podría autorizar accidentalmente todas las entidades de servicio de ese suscriptor además de los usuarios.

Validación del asunto

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

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

O bien,

Puede comprobar que el sujeto pertenece a un rol o grupo adecuado con las notificaciones 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 notificaciones roles, groups o wids 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 notificaciones no son únicas y pueden ser controlables por los administradores de inquilinos o, a veces, los usuarios, lo que las hace no adecuadas 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 notificación scp (ámbito) para validar que la aplicación tenga 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 ausencia de la notificación scp en los siguientes escenarios:

  • Permiso solo para aplicaciones o aplicaciones de demonio
  • Tokens de identificador

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 notificación appid (para los tókenes v1.0) o la notificación azp (para los tókenes v2.0) se pueden usar para la autorización del sujeto. Sin embargo, al usar estas notificaciones, la aplicación debe asegurarse de que el token se haya emitido directamente para la aplicación mediante la validación de la notificació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