SPFx, Azure Functions et Table Storage avec Entra ID

Un défi courant dans le développement SharePoint consiste à permettre aux utilisateurs d’interagir avec des données back-end sans exposer de secrets ni faire entièrement confiance à ce qu’envoie le client. Cet article détaille un modèle qui résout ces deux problèmes : une extension SPFx obtient silencieusement un token Entra ID et l’envoie à une Azure Function qui valide le JWT côté serveur, extrait l’identité de l’utilisateur des claims signés et traite les données dans Azure Table Storage.

Architecture de flux d’identité sécurisé entre SharePoint et Azure.

Architecture

Trois décisions de conception clés définissent ce modèle : le client n’identifie jamais l’utilisateur directement ; l’identité est extraite du token signé, côté serveur. La Function valide elle-même le JWT au lieu de dépendre d’Easy Auth. Enfin, la chaîne de connexion du storage réside exclusivement dans les variables d’environnement de la Function App et reste invisible pour le navigateur.

Étape 1 — Enregistrer l’API App dans Entra ID

Créez un App Registration dans Entra ID pour représenter l’API de l’Azure Function. Dans la section « Expose an API », configurez l’Application ID URI (api://<client-id>) et ajoutez un scope comme access_as_user avec consentement administrateur.

Notez l’Application (client) ID et le Directory (tenant) ID ; la Function a besoin des deux pour valider les tokens.

Étape 2 — Configurer l’extension SPFx

Dans le fichier package-solution.json du projet, déclarez une entrée webApiPermissionRequests indiquant la ressource et le scope de l’App Registration. Après le déploiement du paquet .sppkg, un administrateur SharePoint doit approuver la demande dans le SharePoint Admin Center, sous « API access ».

Une fois la demande approuvée, le composant AadHttpClient de SPFx gère l’obtention du token de manière transparente. L’utilisateur est déjà connecté à SharePoint via Entra ID : le token est donc obtenu silencieusement (sans fenêtre pop-up ni redirection) et joint en tant qu’en-tête Bearer à chaque requête. Le payload de la requête ne doit contenir que des données métier ; l’identité de l’utilisateur n’y est jamais ajoutée manuellement.

Étape 3 — Azure Function avec validation manuelle du JWT

Au lieu de déléguer l’authentification à Easy Auth au niveau de l’hôte, la Function valide explicitement les tokens. Elle lit l’en-tête Authorization, extrait le token Bearer et le vérifie à l’aide des clés de signature publiées par Microsoft (l’endpoint JWKS de votre tenant).

La validation vérifie :

aud (audience) : le token est destiné spécifiquement à votre App Registration.
iss (issuer) et tid (tenant) : le token a été émis par votre tenant Entra ID.
Signature : le token est signé cryptographiquement par Microsoft et ne peut pas être falsifié.

L’authLevel de la Function est défini sur anonymous, ce qui désactive simplement le mécanisme de clés intégré d’Azure Functions. La validation personnalisée du token au début de chaque gestionnaire constitue le véritable point de contrôle de sécurité.

Étape 4 — Azure Table Storage

Créez un Storage Account et une table, puis enregistrez le nom du compte, la clé, le tenant ID et l’audience attendue dans Configuration -> Application Settings de la Function App. L’extension SPFx ignore tout du compte de stockage et de ses identifiants.

Lorsque la Function écrit des entités, elle les enrichit avec l’identité extraite du token : des champs comme createdBy ou modifiedBy sont remplis à partir des JWT claims, jamais à partir du corps de la requête envoyé par le client.

Conclusion

Ce modèle (extension SPFx, Azure Functions et Azure Table Storage, intégrés à Entra ID) offre à SharePoint une couche de données légère et serverless. Le principe fondamental : ne faites pas confiance au client pour l’identité. Laissez Entra ID signer le token, la Function le valider et déterminer qui est l’utilisateur, et limitez le rôle du client à l’envoi de données métier accompagnées d’un token Bearer valide.