Conectar n8n a SharePoint devuelve 403 en cada acción del nodo, a pesar de que la credencial muestra como conectada exitosamente. Esto persiste incluso después de cambiar de permisos de Aplicación a Delegados como se sugiere en otros hilos.
403 - Forbidden
Access denied
Check your credential
Lo que ya hemos intentado
Registrar una aplicación de Azure con URL de devolución de llamada OAuth según la documentación de n8n
Generar un secreto de cliente
Comenzar con permisos de Aplicación (Sites.Read.All, Sites.ReadWrite.All) + consentimiento del administrador → 403
Cambiar a permisos Delegados (Sites.ReadWrite.All, Files.ReadWrite.All) + consentimiento del administrador → aún 403
Omitir SearchConfiguration.* completamente (no pudimos añadirlos en nuestro tipo de aplicación de todas formas)
Confirmar que el usuario autenticado tiene acceso directo al sitio de SharePoint (se abre bien en el navegador)
Reconectar la credencial en n8n después de cada cambio
Detalle clave: el usuario que autentica el flujo OAuth ha confirmado acceso por navegador al sitio de SharePoint. El problema no es falta de pertenencia a nivel de sitio.
Configuración
Detalle
Valor
Hosting de n8n
Cloud
SharePoint
SharePoint Online (Microsoft 365)
Tipo de registro de aplicación
Cuentas en cualquier directorio organizacional (Multiinquilino)
Usuario de autenticación
Cuenta organizacional personal
Configuración de Azure realizada por
Administrador del sistema (independiente del usuario de n8n)
Lo que sospecho
Es posible que el token OAuth no esté recogiendo los ámbitos correctos, o hay una discrepancia entre lo que Azure está emitiendo y lo que la API de SharePoint espera. El hecho de que la verificación de conexión de credenciales pase independientemente del tipo de permiso sugiere que la prueba de conexión de n8n no está validando realmente el acceso a la API de Graph.
@Daniel.k96 has estado peleando contra la capa equivocada, no son tus permisos de Azure, es el scope que n8n realmente solicita. La credencial Microsoft SharePoint OAuth2 solicita un scope muy limitado (básicamente openid profile offline_access), así que el token regresa SIN Sites.ReadWrite.All aunque hayas otorgado y consentido en Azure, y SharePoint devuelve 403 porque el token no lleva ningún scope de Sites. es un problema conocido, n8n amplió los valores por defecto en una compilación reciente.
solución: abre esa credencial, establece explícitamente el campo Scope en
openid profile offline_access Sites.ReadWrite.All Files.ReadWrite.All
luego reconecta para que vuelva a pedir consentimiento con esos scopes.
para confirmar, pega el access token en jwt.ms y verifica el claim scp, en este momento le falta Sites, esa es la prueba definitiva. el redirect-uri y el asunto del multitenant no es, una discrepancia rompe el paso de conexión, no un 403 después.
Sí. Dado que estás en n8n Cloud, no puedes interceptar fácilmente el tráfico de red, pero puedes usar un nodo HTTP Request para “filtrar” el token hacia ti mismo:
Crea un nodo HTTP Request.
Usa las mismas credenciales de SharePoint.
Establece la URL a https://graph.microsoft.com/v1.0/me.
Si funciona, el token es válido para el usuario. Para ver los ámbitos, puedes usar una herramienta como jwt.ms (el decodificador oficial de Microsoft). Sin embargo, n8n no expone el token sin procesar en la interfaz de usuario. Para obtenerlo, necesitarías usar una herramienta como Postman para realizar el flujo OAuth con tu Client ID/Secret y luego pegar el access_token resultante en jwt.ms. Busca la afirmación scp (scopes).
Sí. Si el URI de redirección estuviera mal emparejado, el flujo OAuth fallaría inmediatamente con una página de error Redirect URI mismatch de Microsoft antes de que volviera a n8n. Dado que tu credencial está «Conectada», el URI es correcto.
Single-tenant para tu caso de uso. Aunque Multitenant puede funcionar, introduce capas de consentimiento adicionales. Si solo accedes a datos dentro de tu propia organización, cambia a «Cuentas solo en este directorio organizacional (Single tenant)». Esto garantiza que el token se emita específicamente para el contexto de seguridad de tu inquilino y simplifica la propagación de permisos.
No aplicable en tu caso, ya que estás en n8n cloud
Hay una cosa más que vale la pena verificar además de lo que cubrió kjooleng: para permisos de aplicación específicamente, solo el consentimiento del administrador de AAD no es suficiente para SharePoint Online. Microsoft requiere que tu aplicación de Azure también tenga acceso explícitamente otorgado a nivel de colección de sitios. Tu administrador del sistema puede hacer esto con el comando de PnP PowerShell: Grant-PnPAzureADAppSitePermission -AppId <your-app-id> -DisplayName <app-name> -Site https://tenant.sharepoint.com/sites/yoursite -Permissions Write. Sin este paso, la prueba de credenciales pasa (porque solo valida el token OAuth), pero las llamadas reales a la API de SharePoint fallarán con 403 porque la aplicación no se reconoce como que tenga acceso a nivel de sitio.
prueba el flujo delegado con Single-tenant primero antes de nada. Las aplicaciones multitenant suelen obtener un token genérico que la API de SharePoint rechaza incluso con los scopes correctos, porque el contexto del tenant no está fijado. Cambia a Single-tenant en Azure, reconecta y prueba de nuevo.
Además, una forma rápida de confirmar que el arreglo del scope funcionó sin Postman: añade un nodo HTTP Request usando tu credential de SharePoint y llamada:
Si eso devuelve datos, tu token es válido y tiene los scopes correctos. Si también devuelve 403, el problema es el token en sí, no el nodo de SharePoint.
Un caso más especial: si tu organización tiene Conditional Access Policies en SharePoint (común en configuraciones empresariales de M365), el token OAuth puede pasar pero aún así bloquearse a nivel de recurso. Pídele a tu administrador de sistemas que revise los registros de inicio de sesión de Azure AD para tu aplicación, mostrará exactamente por qué el token fue rechazado.
Esto parece ser más un problema de orientación de sitio/recurso de SharePoint que un problema básico de conexión OAuth. Verificaría el ID de sitio exacto/unidad/alcance de lista que n8n está llamando, luego probaría el mismo token con Graph Explorer o un nodo HTTP Request sin procesar para que puedas separar «la credencial funciona» de «este recurso está permitido». Si compartes la operación del nodo y la forma de URL del sitio saneada, puedo ayudarte a reducir la discrepancia de permisos.