SPFx, Azure Functions e Table Storage com Entra ID

Um desafio comum no desenvolvimento para SharePoint é permitir que os usuários interajam com dados do back-end sem expor segredos nem confiar totalmente no que o cliente envia. Este post detalha um padrão que resolve os dois problemas: uma extensão SPFx obtém um token do Entra ID de forma silenciosa e o envia a uma Azure Function que valida o JWT no servidor, extrai a identidade do usuário dos claims assinados e processa os dados no Azure Table Storage.

Arquitetura de fluxo de identidade segura entre o SharePoint e o Azure.

Arquitetura

Três decisões de design fundamentais definem este modelo: o cliente nunca identifica o usuário diretamente; a identidade é extraída do token assinado no servidor. A Function valida o JWT por conta própria, em vez de depender do Easy Auth. E, por fim, a connection string do storage fica exclusivamente nas variáveis de ambiente da Function App, permanecendo invisível para o navegador.

Passo 1 — Registrar a API App no Entra ID

Crie um App Registration no Entra ID para representar a API da Azure Function. Na seção «Expose an API», configure o Application ID URI (api://<client-id>) e adicione um scope como access_as_user com consentimento de administrador.

Anote o Application (client) ID e o Directory (tenant) ID; ambos são necessários na Function para validar os tokens.

Passo 2 — Configurar a extensão SPFx

No arquivo package-solution.json do projeto, declare uma entrada webApiPermissionRequests especificando o recurso e o scope do App Registration. Depois de implantar o pacote .sppkg, um administrador do SharePoint precisa aprovar a solicitação no SharePoint Admin Center, em «API access».

Depois de aprovada, o componente AadHttpClient do SPFx cuida da obtenção do token de forma transparente. O usuário já está autenticado no SharePoint via Entra ID, então o token é obtido silenciosamente (sem janelas pop-up nem redirecionamentos) e anexado como header Bearer em cada requisição. O payload da requisição deve conter apenas dados de negócio; a identidade do usuário nunca é incluída manualmente.

Passo 3 — Azure Function com validação manual do JWT

Em vez de delegar a autenticação ao Easy Auth no nível do host, a Function valida os tokens explicitamente. Ela lê o header Authorization, extrai o token Bearer e o verifica contra as chaves de assinatura publicadas pela Microsoft (o endpoint JWKS do seu tenant).

A validação verifica:

aud (audience): O token é destinado especificamente ao seu App Registration.
iss (issuer) e tid (tenant): O token foi emitido pelo seu tenant do Entra ID.
Signature: O token é assinado criptograficamente pela Microsoft e não pode ser falsificado.

O authLevel da Function é definido como anonymous, o que simplesmente desativa o mecanismo de chaves integrado das Azure Functions. A validação personalizada do token no início de cada handler é o verdadeiro portão de segurança.

Passo 4 — Azure Table Storage

Crie uma Storage Account e uma tabela e depois guarde o nome da conta, a chave, o tenant ID e o audience esperado em Configuration -> Application Settings da Function App. A extensão SPFx não tem nenhum conhecimento da conta de armazenamento nem das suas credenciais.

Quando a Function grava entidades, ela as enriquece com a identidade extraída do token: campos como createdBy ou modifiedBy são preenchidos a partir dos JWT claims, nunca do corpo da requisição enviado pelo cliente.

Conclusão

Este padrão (extensão SPFx, Azure Functions e Azure Table Storage, integrados ao Entra ID) oferece uma camada de dados leve e serverless para o SharePoint. O princípio fundamental: não confie no cliente para a identidade. Deixe o Entra ID assinar o token, a Function validá-lo e determinar quem é o usuário, e que o único trabalho do cliente seja enviar dados de negócio acompanhados de um token Bearer válido.