Como criar Webhooks confiáveis do Microsoft Graph para SharePoint e Microsoft 365
By Mirko Peters ·
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
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
Os Webhooks do Microsoft Graph fornecem notificações em tempo real sobre alterações no Microsoft 365, eliminando a necessidade de consultas constantes (polling).
Garanta que o seu endpoint de webhook esteja acessível publicamente e use HTTPS para manter a segurança e a confiabilidade.
Responda rapidamente às requisições de validação devolvendo o token de validação para ativar sua assinatura de webhook com sucesso.
Implemente uma estratégia robusta de nova tentativa e backoff para lidar com falhas na entrega de notificações e evitar perda de dados.
Automatize as renovações de assinaturas e monitore o seu pipeline de webhooks para garantir notificações contínuas e confiáveis.
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:
Mensagens
Eventos
Contatos
Usuários
Grupos
Conversas
Arquivos do OneDrive
Alertas
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:
Falhas em webhooks podem comprometer a funcionalidade da aplicação caso não sejam tratadas corretamente.
Picos repentinos de tráfego podem sobrecarregar os servidores, levando a indisponibilidade e perda de requisições de webhook.
Não consumir os webhooks pode resultar em perda e inconsistência de dados caso não exista um mecanismo de retransmissão.
URLs de webhook não protegidas podem ser exploradas, permitindo que invasores enviem dados corrompidos.
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:
Crie um endpoint acessível publicamente que use HTTPS. Esse endpoint vai receber as notificações do Microsoft Graph.
Envie uma requisição POST para o endpoint
/subscriptionsno Microsoft Graph.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 | Content-Type | Corpo da resposta | |
|---|---|---|---|---|---|
GET | validationToken=1234 | 200 OK | text/plain | 1234 |
Não devolver o validationToken causa um erro de validação. Isso significa que o Microsoft Graph não consegue confirmar o seu endpoint, e você não vai receber notificações.
Você deve usar a propriedade clientState para verificar se as requisições vêm da sua assinatura.
Sempre retorne o validationToken no corpo da resposta como texto simples, em até 10 segundos.
💡 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.
Adicione uma lista de permissões de IPs para os endpoints da API do Microsoft Graph.
Inclua os tokens de autenticação nos cabeçalhos da requisição.
Monitore o uso da sua API para detectar padrões incomuns ou picos de atividade.
Restrinja o acesso ao Microsoft Graph e às APIs do Outlook. Somente pessoas autorizadas devem ter acesso, e você deve exigir autenticação multifator.
Implemente soluções avançadas de segurança de endpoints que usam análise comportamental e aprendizado de máquina para identificar ameaças.
Realize auditorias de segurança regulares para encontrar e corrigir vulnerabilidades.
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:
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.
Confirme que a plataforma de identidade da Microsoft emitiu o token. Valide a assinatura do token para garantir que ele não foi alterado.
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.
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:
Não verificar a assinatura do JWT pode permitir que atacantes alterem o conteúdo do token sem serem detectados.
Usar o algoritmo 'none' no processamento de JWT permite que atacantes contornem as verificações de assinatura.
Segredos de assinatura fracos facilitam que atacantes forjem tokens válidos.
Atacantes podem injetar parâmetros específicos no cabeçalho JOSE para manipular a forma como seu sistema processa os JWTs.
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:
Verificar se todos os campos obrigatórios estão presentes no payload. Campos ausentes podem causar erros ou processamento incompleto.
Higienize todos os campos de texto antes de exibi-los ou armazená-los no banco de dados. Essa etapa evita ataques de injeção e corrupção de dados.
Use validação de esquema para confirmar que o payload corresponde à estrutura esperada. A validação de esquema ajuda você a identificar alterações inesperadas ou dados malformados.
Prepare seu código para possíveis mudanças de versão da API. Um parsing flexível garante que sua aplicação continue funcionando mesmo que a Microsoft altere o formato do payload.
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 |
Filas de nova tentativa | Filas para tratar as novas tentativas, nomeadas |
Fila de abandono | Uma fila final para mensagens que falharam após todas as tentativas de nova execução, como |
Cálculo do TTL | O tempo de vida (TTL, time-to-live) de cada fila de nova tentativa usa a fórmula: |
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:
Envie requisições HTTP PATCH para atualizar a data de expiração de cada assinatura.
Agende essas requisições PATCH para execução diária. Isso mantém suas assinaturas atualizadas e evita expirações inesperadas.
Acompanhe o carimbo de data/hora de expiração de cada assinatura. Renove qualquer assinatura que esteja próxima de expirar.
Se uma assinatura expirar, crie uma nova imediatamente para restabelecer o fluxo de notificações.
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.
Monitore o status e as datas de expiração das assinaturas.
Configure alertas para renovações com falha ou notificações perdidas.
Registre em log todos os eventos de webhook e erros para solução de problemas.
🛎️ 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.
As consultas delta permitem que sua aplicação acompanhe alterações sem baixar todos os dados a cada vez.
Elas funcionam bem com o SharePoint e o M365, enviando notificações somente quando algo muda.
Você economiza largura de banda e melhora o desempenho ao usar consultas delta.
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:
Mantenha a documentação atualizada e as equipes de suporte informadas.
Agende verificações regulares da integridade das assinaturas.
Use verificações de segurança no pipeline de CI e mantenha trilhas de auditoria.
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.