M365Con 2027 – conferência online gratuita · 11–22 Jan 2027 · 120 sessions→ m365con.net

Blog · Mirko Peters

Como criar Webhooks confiáveis do Microsoft Graph para SharePoint e Microsoft 365

By ·

Crie Webhooks confiáveis do Microsoft Graph para SharePoint e Microsoft 365 com validação segura, renovações automatizadas e entrega robusta de notificações.

Automatically translated with AI from the original post. Read the English original

▶ BLOGHow to Build ReliableMicrosoft Graph Webhoo……M365.FM
Titelbild: How to Build Reliable Microsoft Graph Webhooks for SharePoint and M365

Criar Webhooks confiáveis do Microsoft Graph para SharePoint e Microsoft 365 pode desafiar até desenvolvedores experientes. Você pode encontrar problemas como falhas de validação se o seu endpoint não devolver o token de validação ou não responder com um status 200 OK. Problemas comuns incluem endpoints bloqueados por firewalls, configurações incorretas de rede ou interferência de middleware. Tentativas de reentrega perdidas e assinaturas expiradas costumam acontecer quando o serviço não recebe a requisição de validação ou quando os endpoints não são acessíveis publicamente. Você vai aprender a evitar essas armadilhas e criar um pipeline de notificações robusto e seguro, com uma checklist prática e boas práticas.

Principais conclusões

Fundamentos dos Webhooks do Microsoft Graph

O que são Webhooks do Microsoft Graph

Um webhook é uma requisição HTTP, disparada por um evento em um sistema de origem e enviada a um sistema de destino, geralmente com uma carga de dados. Webhooks são automatizados; em outras palavras, são enviados automaticamente quando o evento é disparado no sistema de origem.

Você usa os Webhooks do Microsoft Graph para receber notificações em tempo real sobre alterações no seu ambiente do Microsoft 365. Isso significa que você não precisa consultar constantemente o Microsoft Graph em busca de atualizações. Em vez disso, sua aplicação é notificada assim que algo importante acontece. Isso mantém você atualizado e sincronizado com os dados acessíveis pelo Microsoft Graph. Também elimina a necessidade de uma infraestrutura de polling, em que você envia requisições frequentes ao Microsoft Graph para verificar as alterações mais recentes.

Você pode configurar notificações para vários tipos de eventos, como:

Por exemplo, você pode querer criar automaticamente uma conta em um sistema de controle de horas de terceiros quando um novo usuário entrar na sua organização. Você também pode disparar o processamento de conteúdo, como relatórios de despesas, quando alguém adicionar um novo arquivo a uma biblioteca de documentos do SharePoint ou a uma pasta do OneDrive.

Por que a confiabilidade importa

Os Webhooks do Microsoft Graph têm papel fundamental em manter as suas integrações com SharePoint e Microsoft 365 responsivas e atualizadas. Quando o seu pipeline de webhooks funciona de forma confiável, suas aplicações reagem às alterações em tempo real. Os usuários sempre veem os dados mais recentes, o que melhora a experiência e reduz o risco de informações desatualizadas.

No entanto, problemas de confiabilidade podem causar sérios transtornos:

Para construir uma solução robusta, você deve combinar webhooks com delta queries para acompanhar as alterações de forma eficiente. Você também precisa criar processos para verificar e renovar as assinaturas regularmente. Para recursos que são atualizados com frequência, o envio em lotes (batching) ajuda a gerenciar a carga.

Configurando e validando Webhooks

Configurar webhooks do Microsoft Graph para SharePoint e Microsoft 365 envolve várias etapas importantes. Você precisa registrar o seu webhook, tratar as solicitações de validação e proteger o seu endpoint. Cada etapa tem um papel decisivo para garantir que o seu pipeline de notificações funcione de forma confiável e segura.

Registrando webhooks do Microsoft Graph

Você começa criando uma assinatura de webhook. Esse processo permite que a sua aplicação receba notificações sobre alterações nos recursos do Microsoft 365. Siga estas etapas para registrar o seu webhook:

  1. Crie um endpoint acessível publicamente que use HTTPS. Esse endpoint vai receber as notificações do Microsoft Graph.

  2. Envie uma requisição POST para o endpoint /subscriptions no Microsoft Graph.

  3. Na sua requisição de assinatura, especifique:

    • changeType: os tipos de alteração que você quer monitorar, como "created", "updated" ou "deleted".

    • notificationUrl: a URL do seu endpoint de webhook.

    • resource: o recurso que você quer monitorar, como "/users" ou "/drive/root".

    • expirationDateTime: a data e hora em que a assinatura deve expirar.

    • Propriedades opcionais, como clientState, ajudam você a verificar a origem das notificações.

Exemplo de requisição de assinatura:

POST https://graph.microsoft.com/v1.0/subscriptions
Authorization: bearer eyJ0eXAiOiJ[..]
Content-Type: application/json

{
  "changeType": "updated",
  "clientState": "SecretClientState",
  "notificationUrl": "https://yourdomain.com/api/notifications",
  "resource": "/users",
  "expirationDateTime": "2024-05-01T00:00:00.0000000+00:00"
}

Você precisa garantir que o seu endpoint esteja acessível publicamente e protegido por HTTPS. O Microsoft Graph valida a URL de notificação antes de concluir a assinatura. Também é necessário renovar as assinaturas regularmente para continuar recebendo notificações. O seu endpoint deve retornar respostas HTTP rápidas e consistentes para não perder notificações.

Aqui está um resumo dos campos obrigatórios para o registro:

Campo

Descrição

changeType

Especifica o tipo de alteração que dispara a notificação (por exemplo, 'updated').

clientState

Uma string personalizada que ajuda a validar a origem da notificação.

notificationUrl

O endpoint para onde as notificações serão enviadas.

resource

O recurso monitorado (por exemplo, '/users').

expirationDateTime

A data e hora em que a assinatura vai expirar.

validationToken

Um token que precisa ser retornado na resposta para validar a requisição de assinatura.

Tratando requisições de validação

Depois que você registra o seu webhook, o Microsoft Graph envia uma requisição de validação para o seu endpoint. Você precisa responder corretamente para concluir o processo de assinatura. Quando o seu endpoint receber uma requisição GET com o parâmetro de consulta validationToken, você deve devolver esse token no corpo da resposta como texto simples e retornar o status 200 OK.

Tipo de requisição

URL

Parâmetro de consulta

Status de resposta esperado

Content-Type

Corpo da resposta

GET

https://yourdomain.com

validationToken=1234

200 OK

text/plain

1234

💡 Dica: Responder rapidamente e com precisão às requisições de validação garante que a assinatura do seu webhook seja ativada sem problemas.

HTTPS e segurança do endpoint

Proteger o endpoint do seu webhook é essencial. Os webhooks do Microsoft Graph exigem criptografia HTTPS para proteger dados sensíveis durante a comunicação. Você deve verificar as requisições recebidas checando a assinatura criada com uma chave secreta compartilhada. Use caminhos complexos e gerados aleatoriamente nas suas URLs de callback para dificultar a adivinhação.

Cada callback de webhook usa um JSON Web Token (JWT) assinado no cabeçalho Authentication da requisição HTTPS de entrada. Você pode usar técnicas padrão de validação de JWT do OpenID Connect para garantir a integridade do token.

Você deve usar HTTPS em todos os endpoints de webhook. Esse requisito protege seus dados e garante conformidade com os padrões de segurança da Microsoft. Proteger seu endpoint ajuda a evitar acessos não autorizados e ataques.

Ao seguir essas etapas, você configura um pipeline confiável e seguro do Microsoft Graph Webhooks para SharePoint e Microsoft 365. Você garante que sua aplicação receba as notificações com rapidez e segurança.

Processando e protegendo as notificações

Depois de configurar seu endpoint de webhook, você precisa processar as notificações recebidas de forma segura e confiável. Essa etapa garante que sua aplicação aceite apenas requisições válidas e que você nunca perca atualizações importantes do Microsoft Graph Webhooks.

Autenticando e verificando tokens JWT

Toda notificação do Microsoft Graph inclui um JSON Web Token (JWT) no cabeçalho Authorization. Você deve verificar esse token antes de processar qualquer payload. A validação adequada do JWT protege seu sistema contra requisições não autorizadas ou adulteradas.

Siga estas etapas para autenticar e verificar tokens JWT:

  1. Verifique se o token não expirou. Os tokens incluem um horário de expiração, e você deve rejeitar qualquer token após esse horário.

  2. Confirme que a plataforma de identidade da Microsoft emitiu o token. Valide a assinatura do token para garantir que ele não foi alterado.

  3. Certifique-se de que a claim "audience" do token corresponde ao ID da sua aplicação. Essa etapa confirma que o token foi destinado ao seu app.

  4. Verifique se a propriedade azp (authorized party) corresponde ao valor esperado para sua aplicação.

Dica: Sempre use bibliotecas confiáveis para validação de JWT. Essas bibliotecas ajudam você a evitar erros comuns e mantêm sua aplicação segura.

Você também deve ficar atento às vulnerabilidades de segurança comuns ao lidar com tokens JWT:

Ao seguir essas etapas e precauções, você garante que apenas notificações legítimas cheguem à sua aplicação.

Tratando os payloads das notificações

Depois de autenticar a notificação, você precisa processar o payload com segurança. Os payloads de notificação contêm informações sobre o evento que disparou o webhook. Para manter a integridade dos dados e evitar problemas de segurança, você deve:

Observação: Validar e higienizar os payloads protege seu sistema contra dados malformados e ameaças de segurança.

Implementando a lógica de retry e backoff

Problemas de rede ou indisponibilidades temporárias podem fazer a entrega de notificações falhar. Para evitar perda de dados, você precisa de uma estratégia robusta de retry e backoff. A Microsoft recomenda usar backoff exponencial e filas estruturadas para gerenciar as novas tentativas.

Aqui está uma tabela que resume os mecanismos comuns de retry e backoff:

Tipo de mecanismo

Descrição

Backoff exponencial

Aumenta o tempo de espera entre as novas tentativas de forma exponencial após cada falha.

Fila principal

A fila inicial onde os eventos de webhook são publicados, como main.webhook.queue.

Filas de nova tentativa

Filas para tratar as novas tentativas, nomeadas retry.webhook.queue-M, em que M é o número da tentativa.

Fila de abandono

Uma fila final para mensagens que falharam após todas as tentativas de nova execução, como abandon.webhook.queue.

Cálculo do TTL

O tempo de vida (TTL, time-to-live) de cada fila de nova tentativa usa a fórmula: {interval} + {current_retry_attempt} ^ 4.

Cabeçalho x-retry

Um cabeçalho que controla o número de tentativas de nova execução de cada mensagem.

Dead Letter Exchange

Um exchange que recebe mensagens que não podem mais ser reprocessadas e as encaminha para a fila de abandono.

Se você não implementar uma lógica adequada de nova tentativa e de backoff, sua aplicação corre o risco de perder notificações ou de gerar inconsistências nos dados. Requisições com falha ou limitação de taxa (rate limiting) podem impedir que você receba atualizações críticas. O backoff exponencial ajuda a gerenciar requisições limitadas e reduz a chance de sobrecarregar seu sistema ou os Webhooks do Microsoft Graph.

🛡️ Melhor prática: Sempre registre as tentativas de nova execução e mova as mensagens com falha para a fila de abandono após algumas tentativas. Essa abordagem permite investigar e resolver problemas persistentes sem perder dados.

Ao autenticar tokens JWT, validar payloads e implementar uma lógica confiável de nova tentativa, você cria um pipeline de notificações seguro e resiliente. Essas etapas ajudam você a processar todas as notificações dos Webhooks do Microsoft Graph com segurança e eficiência.

Gerenciando assinaturas e rastreamento de alterações

Automatizando a renovação de assinaturas

Você precisa manter suas assinaturas de webhook ativas para não perder notificações. As assinaturas do Microsoft Graph expiram após um período definido. Se você não as renovar, sua aplicação deixa de receber atualizações. Você pode automatizar a renovação usando alguns métodos:

Dica: Automatizar as renovações reduz o trabalho manual e garante que seu sistema continue conectado ao Microsoft Graph.

Monitoramento e alertas

Você deve monitorar a integridade do seu pipeline de webhooks. Configure alertas para avisá-lo se uma assinatura não for renovada ou se seu endpoint parar de responder. Use logs para registrar as notificações recebidas e as tentativas de renovação. Isso ajuda você a identificar problemas antes que afetem os usuários.

🛎️ O monitoramento proativo ajuda você a corrigir problemas rapidamente e mantém sua integração confiável.

Usando consultas delta para rastrear alterações

As consultas delta ajudam você a rastrear alterações em recursos do SharePoint e do M365 de forma eficiente. Você pode usá-las para receber apenas dados novos ou atualizados, o que reduz a necessidade de consultas frequentes (polling) e diminui o risco de throttling.

No entanto, as consultas delta têm algumas limitações:

Limitação/Desafio

Descrição

Contexto OData

Retornado incorretamente ao rastrear alterações em relacionamentos.

Extensões de esquema

Não são retornadas com a instrução $select, mas são retornadas sem ela.

Extensões abertas

Clientes não conseguem rastrear alterações em extensões abertas ou extensões de esquema registradas.

Observação: Sempre teste sua implementação de consultas delta para tratar essas limitações e garantir um rastreamento de alterações preciso.

Ao automatizar as renovações, monitorar seu pipeline e usar consultas delta, você cria um sistema de webhooks confiável e eficiente para o SharePoint e o M365.

Você pode criar webhooks confiáveis do Microsoft Graph seguindo um processo claro. Comece criando assinaturas e usando consultas delta para acompanhar as alterações. Automatize as renovações e monitore seu pipeline em busca de problemas. Priorize validação, segurança e resiliência em todas as etapas. Para garantir que a solução esteja pronta para produção, revise esta lista de verificação:

Tipo de medida

Descrição

Verificações de segurança no pipeline de CI

Verifique se há vulnerabilidades antes da implantação.

Trilha de auditoria automatizada

Registre todo build e toda implantação para fins de conformidade e auditorias.

Aplique essas práticas recomendadas para garantir que suas integrações com SharePoint e Microsoft 365 continuem confiáveis.

Perguntas frequentes

Como você renova uma assinatura de webhook do Microsoft Graph expirada?

Envie uma solicitação PATCH para o endpoint /subscriptions/{id} do Microsoft Graph. Atualize o campo expirationDateTime. Agende esse processo para execução diária. Isso mantém suas assinaturas ativas e evita a perda de notificações.

O que fazer se o endpoint do seu webhook falhar na validação?

Verifique se o endpoint retorna o validationToken como texto simples no corpo da resposta. Responda com o status 200 OK. Certifique-se de que o endpoint esteja acessível publicamente e use HTTPS.

Como proteger o endpoint do seu webhook?

Use HTTPS em todos os endpoints. Valide os tokens JWT em todas as requisições. Restrinja o acesso com autenticação e lista de IPs permitidos. Monitore atividades incomuns. Audite regularmente suas configurações de segurança.

Por que você precisa usar consultas delta com webhooks?

Consultas delta ajudam você a acompanhar apenas dados novos ou alterados. Isso reduz o consumo de banda e melhora o desempenho. Você evita baixar todos os dados a cada vez, tornando sua integração mais rápida e eficiente.

Qual é a melhor forma de tratar notificações de webhook que falharam?

Implemente lógica de nova tentativa com backoff exponencial. Acompanhe as tentativas usando cabeçalhos ou filas. Mova as mensagens que falharem após várias tentativas para uma fila de descarte. Investigue essas falhas para evitar perda de dados.

Microsoft Graph Change notifications and webhooks SharePoint OneDrive Microsoft 365

Related articles

RSS