Authenticatie

Iedereen die de URL van een webhook kent, kan er een verzoek naar sturen. Authenticatie zorgt er dus voor dat een onbekende geen workflows in uw Shopify Flow kan activeren. Stel dit per webhook in, onder het gedeelte ‘Beveiliging’ van de betreffende webhook.

De drie methoden

Methode	Hoe de beller zijn identiteit aantoont	Gebruik dit wanneer
Geen	Niets	Uitsluitend voor testdoeleinden - nooit in productie
Statisch token	Een vast geheim in een verzoekheader	Vrijwel elke integratie (n8n, Make, Zapier, uw eigen code)
HMAC SHA-256	Een handtekening die is berekend op basis van het verzoek en een gedeeld geheim	De afzender ondertekent zijn webhooks (Stripe, GitHub, Slack, …)

Statisch token

Druk op de knop ‘Genereren’ op de webhook om een sterk willekeurig token te verkrijgen, of plak uw eigen token. De aanroeper verstuurt dit in een header:

De webhook-editor: naam en authenticatie aan de linkerkant, de Endpoint-kaart met status, webhook-URL en webhook-ID aan de rechterkant, met daarboven ‘Live Preview’, ‘Test’ en ‘Usage’ — Een statisch token: kies hoe de afzender het token doorgeeft, genereer of plak het token en kopieer de webhook-URL van de Endpoint-kaart.

bash

curl -X POST https://your-app-url/webhook/ab12cd34 \
  -H "Content-Type: application/json" \
  -H "X-Api-Key: your-token" \
  -d '{"orderId":"1001"}'

De naam van de koptekst wijzigen

Sommige systemen kunnen alleen een header verzenden die zij al gebruiken. Stel de naam van de Auth-header in onder „Geavanceerde instellingen“ in, dan lezen wij het token uit die header in plaats van uit X-Api-Key:

bash

  -H "X-Custom-Auth: your-token"

Bij header-namen wordt geen onderscheid gemaakt tussen hoofdletters en kleine letters. Gereserveerde namen worden geweigerd - Host, Authorization, Cookie, X-Forwarded-*, X-Webhook-*, CF-* en dergelijke. Deze worden door proxyservers en CDN’s ingesteld of herschreven, waardoor een token dat daaruit wordt gelezen door een aanvaller zou kunnen worden beïnvloed.

Waar het token naartoe gaat

Niet elke afzender kan een willekeurige header toevoegen. Hoe geeft de afzender het token door? Op het tabblad ‘Webhook’ zijn er vier mogelijkheden:

Keuze	De afzender verzendt	Gebruik dit wanneer
In een aangepaste koptekst	`X-Api-Key: <token>` of de koptekstnaam die u kiest	De standaardinstelling, en wat bij de meeste integraties het geval is
Als een ‘Bearer’-token	`Authorization: Bearer <token>`	De tool beschikt over een veld voor een Bearer- of API-token
Als gebruikersnaam en wachtwoord	HTTP Basic, met een door u gekozen gebruikersnaam en het token als wachtwoord	De tool ondersteunt uitsluitend Basic-authenticatie
In de URL	`?token=<token>` of de door u gekozen parameternaam	De afzender kan alleen een gewone URL aanroepen en kan geen headers instellen

Authorization De naam van de aangepaste header wordt bewust gereserveerd: „Bearer“ en „Basic“ zijn de ondersteunde manieren om deze te gebruiken, en beide worden automatisch voor u afgehandeld. Bij een 401 voor deze twee wordt ook een WWW-Authenticate-header meegestuurd, omdat verschillende HTTP-clients hun inloggegevens pas verzenden nadat zij hierom zijn gevraagd.

De URL-optie is de zwakste van de vier - URL’s komen terecht in logbestanden, verwijzingsgegevens en de browsergeschiedenis - dus gebruik deze alleen wanneer de afzender u geen andere keuze laat. De app toont de voltooide URL met het token erin en maskeert die parameter overal waar het verzoek wordt opgeslagen.

HMAC SHA-256

De afzender berekent een handtekening over het verzoek met behulp van een gedeeld geheim; wij berekenen deze opnieuw en vergelijken de resultaten. Een uitgelekt verzoek kan niet met gewijzigde inhoud worden herhaald, omdat de inhoud dan niet meer overeenkomt met de handtekening.

Voorinstellingen van de provider

Kies uw afzender onder ‘Handtekeningprovider’ en wij voeren de verificatie uit volgens het exacte schema van die provider - de naam van de header, de codering, wat er wordt ondertekend en hoe lang een handtekening geldig blijft. Plak het ondertekeningsgeheim vanuit het dashboard van die provider en u bent klaar.

Er zijn 22 ingebouwde providers, elk met een eigen installatiehandleiding: Calendly, Customer.io, GitHub, Lemon Squeezy, Linear, Mollie, Paddle, Paystack, Razorpay, Sanity, Sendcloud, Sentry, Shopify, Slack, Square, Standaard webhooks (OpenAI, Supabase), Stripe, Svix (Clerk, Resend), Typeform, Vercel, WooCommerce en Zendesk. Mocht uw provider er niet bij staan, beschrijf dan hoe deze verbinding maakt via een aangepast schema.

Zie Gecertificeerde webhooks verifiëren voor de volledige lijst, de aangepaste optie en de ingebouwde handtekeningcontrole.

Een webhook met HMAC-authenticatie en Stripe als handtekeningprovider, waarin het veld ‘signing secret’ wordt weergegeven, wat hiermee wordt gecontroleerd en de stappen voor het koppelen van Stripe — Een ondertekende afzender, in dit geval Stripe: kies de aanbieder, plak het ondertekeningsgeheim en de editor toont wat er is aangevinkt en hoe u de verbinding tot stand kunt brengen.

Generieke HMAC

Aangezien er geen vooraf ingesteld schema en geen aangepast schema is, gebruiken wij ons eigen schema: de aanroeper verzendt X-Signature, de HMAC-SHA256 van de waarden in de X-Webhook-*-header, waarbij gebruik wordt gemaakt van de ondertekeningssleutel.

bash

curl -X POST https://your-app-url/webhook/ab12cd34 \
  -H "Content-Type: application/json" \
  -H "X-Webhook-Data: value1value2" \
  -H "X-Signature: <hmac-sha256 of the X-Webhook-* values>" \
  -d '{"data":"payload"}'

Hoe een afwijzing eruitziet

Bij mislukte authenticatie wordt een 401-foutmelding geretourneerd met een JSON-body waarin de reden wordt vermeld - zie Geschiedenis en probleemoplossing voor de volledige lijst met codes. Afgewezen verzoeken worden nog steeds weergegeven in de Live Request Inspector terwijl u de webhook bewerkt, zodat u precies kunt zien waarom een verzoek is afgewezen.

Het geheim rouleren zonder uitval

Het wijzigen van een geheim in één stap houdt in dat elk verzoek dat met het oude geheim is ondertekend, mislukt totdat de afzender de wijziging heeft doorgevoerd. Door het geheim via de webhook te vernieuwen, wordt dit voorkomen: de webhook bevat een tweede geldig geheim dat naast het hoofdgeheim wordt geaccepteerd, zowel voor het statische token als voor elk ondertekeningsschema.

Voer het nieuwe wachtwoord in bij ‘Tweede geldig wachtwoord’ en sla het op. Beide worden nu geaccepteerd.
Stel de afzender in op het nieuwe geheim.
Klik op ‘Promote’, waardoor het item naar het hoofdveld wordt verplaatst en het tweede veld wordt gewist, en sla het op.

Er wordt op geen enkel moment een verzoek afgewezen. Het tweede geheim wordt op precies dezelfde manier opgeslagen als het hoofdgeheim en wordt nooit door de API teruggestuurd - er wordt alleen aangegeven of er een is ingesteld.

Het geheim veilig bewaren

Het token wordt door onze REST API of MCP-server op geen enkel toegangsniveau teruggegeven - deze Geef alleen aan of er één is ingesteld. Zie API voor ontwikkelaars en MCP.
De gegevens zijn in rust versleuteld.
Het draaien heeft onmiddellijk effect, dus gebruik de hierboven beschreven ‘second-secret’-Shopify Flow in plaats van waardoor het hoofdveld wordt overschreven.
De opgeslagen oproepgeschiedenis verbergt de authenticatieheader, de Basic-inloggegevens en het URL-token, Een schermafbeelding van de geschiedenis leidt dus niet tot het uitlekken van uw geheim.

Het nog verder beperken

Authenticatie bewijst dat de beller het geheim kent. IP-toegangslijsten beperkt de bron van een oproep en kan worden gecombineerd met elk van de bovengenoemde modi.