Solicitudes de acceso a API en SharePoint: qué estás aprobando exactamente
Última actualización:
Cuando un paquete de SharePoint Framework necesita llamar a una API más allá del propio SharePoint, no puede hacerlo sin más. Declara la solicitud en su manifiesto, y esa solicitud aparece en Centro de administración de SharePoint → Avanzado → Acceso a API como pendiente hasta que un administrador la aprueba. No pasa nada hasta que pulsas el botón.
Dos cosas deciden cuánto estás cediendo, y las dos están en esa pantalla: el recurso (de quién es la API) y el scope (qué puede hacer ahí). Microsoft Graph — Sites.Read.All y Contoso — Widgets.Read tienen la misma pinta y son mundos distintos: el primero abre todos los sitios de SharePoint del tenant a esa aplicación; el segundo no concede absolutamente nada sobre tus datos.
Las aprobaciones de aquí son además para todo el tenant, no por sitio, y se aplican a cualquier solución SPFx que pida ese mismo scope, no solo a la que tenías en mente.
Cómo se lee una solicitud
| Campo | Qué te dice |
|---|---|
| Recurso | De quién es la API a la que se llama. Microsoft Graph significa tus datos de Microsoft 365. El nombre de un proveedor significa el servicio de ese proveedor. |
| Scope | El permiso en sí. Lee el verbo (Read, ReadWrite) y la amplitud (.All significa en todo el tenant, no solo lo que el usuario ve). |
| Paquete | Qué solución desplegada lo ha pedido. Si no la reconoces, averígualo antes de aprobar. |
La costumbre más útil de todas: lee el sufijo. Sites.Read.All no es una versión un poco más grande de Sites.Read — el .All significa que el permiso aplica a todo el tenant, y combinado con un permiso de aplicación deja de estar limitado por quién esté mirando la página.
Permisos delegados frente a permisos de aplicación
Esta es la distinción que más importa y sobre la que menos claros son los proveedores.
| Delegado | De aplicación (app-only) | |
|---|---|---|
| Actúa como | El usuario autenticado | La propia aplicación, sin usuario de por medio |
| Limitado por los permisos del usuario | Sí: quien no puede abrir una lista tampoco la ve a través del componente | No: alcanza todo lo que permita el scope |
| Funciona sin nadie delante | No | Sí, incluidos procesos en segundo plano |
| Riesgo si comprometen al proveedor | Acotado por el acceso de cada usuario | Acotado solo por el scope |
Los paquetes de SharePoint Framework piden permisos delegados por esta pantalla, y eso es una propiedad de seguridad relevante: el componente hereda los límites de quien está mirando la página. Los permisos de aplicación existen, pero se conceden directamente a una app de Entra ID y no por la página de acceso a API de SharePoint — así que si un proveedor te pide consentir algo en el portal de Entra en vez de aquí, eso merece una pregunta.
Qué solicitudes deberían hacerte parar
- Cualquier scope
.Allde Microsoft Graph para un componente cuyo trabajo es enseñar algo en una página. Un tracker no necesita leer todos los sitios del tenant. ReadWritedonde bastaríaRead. Pide al proveedor que justifique la escritura, por escrito.- Scopes de directorio o de usuarios (
User.Read.All,Directory.Read.All) en un componente que no sea un organigrama o un directorio de personas. - Scopes de correo, calendario o archivos en cualquier cosa que no sea explícitamente un producto de correo, calendario o archivos.
- Una solicitud que no puedas mapear a una función. Si nadie sabe nombrar la funcionalidad que la necesita, no se aprueba.
El patrón sano es el contrario: un paquete que pide un scope estrecho contra la propia API del proveedor, y que lee tus listas en el navegador con la sesión del usuario — así no hay concesión sobre el tenant que dar ni nada que revocar después más allá del propio paquete. Ese es el modelo de Sharelio, y el manifiesto completo está publicado en sharelio.com/es/seguridad.
Cómo se revoca
- Centro de administración de SharePoint → Avanzado → Acceso a API.
- Busca el permiso aprobado, selecciónalo y elige Quitar.
- Si además quieres eliminar el paquete, bórralo del catálogo de aplicaciones. Quitar solo el permiso deja el paquete desplegado pero sin poder llamar a la API.
Revocar es inmediato y no toca tu contenido: los permisos gobiernan el acceso, no los datos. Merece la pena poner en el calendario una revisión periódica de esta página — las aprobaciones se acumulan en silencio, y paquetes retirados hace años a veces dejan atrás sus concesiones.
Preguntas frecuentes
¿Aprobar una solicitud le da al proveedor acceso a nuestro tenant?
Solo si el recurso es Microsoft Graph u otra API de Microsoft que custodie tus datos. Si el recurso es la propia API del proveedor, aprobar permite al web part obtener un token dirigido a ese proveedor y nada más: no concede acceso a tus sitios, archivos, correo ni directorio. Lo que decide esto es la columna del recurso, no el marketing del proveedor.
¿Es lo mismo que conceder consentimiento de administrador en Entra ID?
No, y la diferencia importa. Aprobar aquí está acotado a lo que pueden pedir las soluciones de SharePoint Framework y lo gestiona el rol de administrador de SharePoint. Conceder consentimiento de administrador a una aplicación en el portal de Entra es una acción más amplia, necesita administrador global o administrador de roles con privilegios, y no es algo a lo que un paquete SPFx pueda obligarte.
¿Podemos aprobar un permiso solo para un departamento?
No. Las aprobaciones de acceso a API son para todo el tenant. Si necesitas limitar quién usa un componente, hazlo con permisos de sitio —controlando quién puede colocar el web part y quién llega a los sitios donde está— en vez de esperar que la concesión del permiso venga acotada.
Un paquete que ya teníamos desplegado tiene de repente una solicitud pendiente. ¿Por qué?
Porque una versión nueva la ha pedido. Eso es una característica, no un fallo: un paquete no puede adquirir permisos en silencio al actualizarse. La solicitud nueva se queda pendiente, sin efecto, hasta que un administrador la apruebe — y ese es vuestro momento para preguntarle al proveedor qué ha cambiado.