SPFx, Azure Functions e Table Storage con Entra ID

Una sfida comune nello sviluppo per SharePoint è permettere agli utenti di interagire con i dati del back-end senza esporre segreti e senza fidarsi completamente di ciò che invia il client. Questo post descrive un pattern che risolve entrambi i problemi: un’estensione SPFx ottiene in modo silenzioso un token di Entra ID e lo invia a una Azure Function che valida il JWT lato server, estrae l’identità dell’utente dai claim firmati ed elabora i dati in Azure Table Storage.

Architettura del flusso di identità sicuro tra SharePoint e Azure.

Architettura

Tre scelte di progettazione fondamentali definiscono questo modello: il client non identifica mai direttamente l’utente; l’identità viene estratta dal token firmato sul server. La Function valida il JWT da sola invece di affidarsi a Easy Auth. Infine, la stringa di connessione dello storage risiede solo nelle variabili d’ambiente della Function App e resta invisibile al browser.

Passo 1 — Registrare l’API App in Entra ID

Crea un App Registration in Entra ID che rappresenti l’API della Azure Function. Nella sezione «Expose an API», configura l’Application ID URI (api://<client-id>) e aggiungi uno scope come access_as_user con il consenso dell’amministratore.

Annota l’Application (client) ID e il Directory (tenant) ID: entrambi servono alla Function per validare i token.

Passo 2 — Configurare l’estensione SPFx

Nel file package-solution.json del progetto, dichiara una voce webApiPermissionRequests indicando la risorsa e lo scope dell’App Registration. Dopo aver distribuito il pacchetto .sppkg, un amministratore di SharePoint deve approvare la richiesta nello SharePoint Admin Center, alla voce «API access».

Una volta approvata, il componente AadHttpClient di SPFx gestisce l’ottenimento del token in modo trasparente. L’utente ha già effettuato l’accesso a SharePoint tramite Entra ID, quindi il token viene ottenuto in silenzio (senza finestre pop-up né reindirizzamenti) e allegato come header Bearer a ogni richiesta. Il payload della richiesta deve contenere solo dati di business; l’identità dell’utente non viene mai inclusa manualmente.

Passo 3 — Azure Function con validazione manuale del JWT

Invece di delegare l’autenticazione a Easy Auth a livello di host, la Function valida i token in modo esplicito. Legge l’header Authorization, estrae il token Bearer e lo verifica con le chiavi di firma pubblicate da Microsoft (l’endpoint JWKS del tuo tenant).

La validazione controlla:

aud (audience): il token è destinato specificamente al tuo App Registration.
iss (issuer) e tid (tenant): il token è stato emesso dal tuo tenant di Entra ID.
Signature: il token è firmato crittograficamente da Microsoft e non può essere falsificato.

L’authLevel della Function è impostato su anonymous, il che disattiva semplicemente il meccanismo di chiavi integrato di Azure Functions. La validazione personalizzata del token all’inizio di ogni handler è il vero cancello di sicurezza.

Passo 4 — Azure Table Storage

Crea uno Storage Account e una tabella, poi salva il nome dell’account, la chiave, il tenant ID e l’audience atteso in Configuration -> Application Settings della Function App. L’estensione SPFx non sa nulla dell’account di archiviazione né delle sue credenziali.

Quando la Function scrive le entità, le arricchisce con l’identità estratta dal token: campi come createdBy o modifiedBy vengono compilati dai JWT claim, mai dal corpo della richiesta inviato dal client.

Conclusione

Questo pattern (estensione SPFx, Azure Functions e Azure Table Storage, integrati con Entra ID) offre a SharePoint un livello dati leggero e serverless. Il principio fondamentale: non fidarti del client per l’identità. Lascia che sia Entra ID a firmare il token, che la Function lo validi e stabilisca chi è l’utente, e che l’unico compito del client sia inviare dati di business insieme a un token Bearer valido.