SPFx, Azure Functions y Table Storage con Entra ID

Un desafío común en el desarrollo de SharePoint es permitir que los usuarios interactúen con datos del back-end sin exponer secretos ni confiar plenamente en lo que el cliente envía. Este post detalla un patrón que resuelve ambos problemas: una extensión de SPFx adquiere un token de Entra ID de forma silenciosa, lo envía a una Azure Function que valida el JWT del lado del servidor, extrae la identidad del usuario de los claims firmados y procesa los datos en Azure Table Storage.

Arquitectura de flujo de identidad segura entre SharePoint y Azure.

Arquitectura

Tres decisiones de diseño clave definen este modelo: el cliente nunca identifica al usuario directamente; la identidad se extrae del token firmado en el servidor. La Function valida el JWT por sí misma en lugar de depender de Easy Auth. Y, por último, la cadena de conexión de storage reside exclusivamente en las variables de entorno de la Function App, permaneciendo invisible para el navegador.

Paso 1 — Registrar la API App en Entra ID

Cree un App Registration en Entra ID para representar la API de la Azure Function. Bajo la sección «Expose an API», configure el Application ID URI (api://<client-id>) y añada un scope como access_as_user con consentimiento de administrador.

Tome nota del Application (client) ID y del Directory (tenant) ID; ambos son necesarios en la Function para la validación de tokens.

Paso 2 — Configurar la extensión SPFx

En el archivo package-solution.json del proyecto, declare una entrada webApiPermissionRequests especificando el recurso y el scope del App Registration. Tras desplegar el paquete .sppkg, un administrador de SharePoint debe aprobar la solicitud en el SharePoint Admin Center bajo «API access».

Una vez aprobada, el componente AadHttpClient de SPFx gestiona la adquisición del token de forma transparente. El usuario ya ha iniciado sesión en SharePoint vía Entra ID, por lo que el token se obtiene silenciosamente (sin ventanas emergentes ni redirecciones) y se adjunta como un encabezado Bearer en cada solicitud. El payload de la solicitud solo debe contener datos de negocio; la identidad del usuario nunca se incluye manualmente.

Paso 3 — Azure Function con validación manual de JWT

En lugar de delegar la autenticación a Easy Auth en el nivel de host, la Function valida los tokens explícitamente. Lee el encabezado Authorization, extrae el Bearer token y lo verifica contra las llaves de firma publicadas por Microsoft (el endpoint JWKS de su tenant).

La validación comprueba:

aud (audience): El token está dirigido específicamente a su App Registration.
iss (issuer) y tid (tenant): El token fue emitido por su tenant de Entra ID.
Signature: El token está firmado criptográficamente por Microsoft y no puede ser falsificado.

El authLevel de la Function se establece como anonymous, lo cual simplemente desactiva el mecanismo de llaves integrado de Azure Functions. La validación personalizada del token al inicio de cada controlador es la verdadera puerta de seguridad.

Paso 4 — Azure Table Storage

Cree una Storage Account y una tabla, luego guarde el nombre de la cuenta, la clave, el tenant ID y el audience esperado en el Configuration -> Application Settings de la Function App. La extensión SPFx no tiene conocimiento alguno de la cuenta de almacenamiento ni de sus credenciales.

Cuando la Function escribe entidades, las enriquece con la identidad extraída del token: campos como createdBy o modifiedBy se completan desde los JWT claims, nunca desde el cuerpo de la solicitud enviado por el cliente.

Conclusión

Este patrón (extensión SPFx, Azure Functions y Azure Table Storage, integrados con Entra ID) ofrece una capa de datos ligera y serverless para SharePoint. El principio fundamental: no confíe en el cliente para la identidad. Permita que Entra ID firme el token, que la Function lo valide y determine quién es el usuario, y que el único trabajo del cliente sea enviar datos de negocio acompañados de un token Bearer válido.