Autentisering

Vem som helst som känner till en webhook-URL kan skicka en begäran till den, så det är autentiseringen som förhindrar att en främling aktiverar dina Shopify Flow-arbetsflöden. Ställ in detta för varje enskild webhook under avsnittet ”Säkerhet” för respektive webhook.

De tre metoderna

Metod	Hur den som ringer identifierar sig	Använd den när
Inget	Ingenting	Endast för teständamål - får aldrig användas i produktion
Statisk token	En fast hemlighet i en begärandehuvud	Nästan alla integrationsmöjligheter (n8n, Make, Zapier, din egen kod)
HMAC SHA-256	En signatur som beräknats utifrån begäran och en gemensam hemlig nyckel	Avsändaren signerar sina webhooks (Stripe, GitHub, Slack, …)

Statisk token

Klicka på knappen ”Generera” i webhooken för att få ett starkt slumpmässigt token, eller klistra in ditt eget. Den som anropar skickar det i en rubrik:

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

Ändra rubrikens namn

Vissa system kan endast skicka en rubrik som de redan använder. Ange namnet på Auth-rubriken i Avancerade inställningar så läser vi in token från den rubriken istället för X-Api-Key:

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

Stor- och småbokstäver spelar ingen roll i rubriknamn. Reserverade namn avvisas - Host, Authorization, Cookie, X-Forwarded-*, X-Webhook-*, CF-* och liknande. Dessa sätts eller skrivs om av proxyservrar och CDN:er, vilket innebär att ett token som läses från en sådan skulle kunna kontrolleras av en angripare.

Vart token tar vägen

Det är inte alla avsändare som kan lägga till en godtycklig rubrik. Hur skickar avsändaren vidare tokenet? På fliken ”Webhook” finns fyra alternativ:

Val	Avsändaren skickar	Använd den när
I en anpassad rubrik	X-Api-Key: <token> eller det rubriknamn du väljer	Standardinställningen, och hur de flesta integrationer fungerar
Som en innehavartoken	Authorization: Bearer <token>	Verktyget har ett fält för bärartoken eller API-token
Som användarnamn och lösenord	HTTP Basic, med ett användarnamn som du själv väljer och token som lösenord	Verktyget stöder endast grundläggande autentisering
I webbadressen	?token=<token> eller det parameternamn du väljer	Avsändaren kan endast anropa en vanlig URL och kan inte ange rubriker

Authorization är avsiktligt ett reserverat namn på en anpassad rubrik: Bearer och Basic är de metoder som stöds för att använda den, och båda hanteras automatiskt åt dig. Ett 401-fel för dessa två metoder åtföljs också av en WWW-Authenticate-rubrik, eftersom flera HTTP-klienter endast skickar inloggningsuppgifter efter att ha blivit ombedda att göra det.

URL-alternativet är det svagaste av de fyra - URL:er hamnar i loggar, hänvisningskällor och webbläsarhistoriken - så använd det endast när avsändaren inte ger dig något annat val. Appen visar den färdiga URL:en med tokenet inkluderat och döljer den parametern överallt där den lagrar begäran.

HMAC SHA-256

Avsändaren beräknar en signatur för begäran med hjälp av en gemensam hemlig nyckel; vi beräknar den på nytt och jämför. En läckt begäran kan inte återanvändas med ändrat innehåll, eftersom huvudtexten inte längre stämmer överens med signaturen.

Förinställningar för leverantörer

Välj din avsändare under ”Signaturleverantör” så verifierar vi enligt just den leverantörens exakta schema - rubriknamn, kodning, vad som signeras och hur länge signaturen är giltig. Klistra in signaturnyckeln från leverantörens kontrollpanel, så är du klar.

Det finns 22 inbyggda tjänsteleverantörer, var och en med sin egen installationsguide: Calendly, Customer.io, GitHub, Lemon Squeezy, Linear, Mollie, Paddle, Paystack, Razorpay, Sanity, Sendcloud, Sentry, Shopify, Slack, Square, Standard Webhooks (OpenAI, Supabase), Stripe, Svix (Clerk, Resend), Typeform, Vercel, WooCommerce och Zendesk. Om din tjänst inte finns med, beskriv hur den signerar med ett anpassat schema.

Se Verifiering av signerade webhooks för en fullständig lista, det anpassade alternativet och den inbyggda signaturkontrollen.

Generisk HMAC

Eftersom det varken finns något förinställt eller anpassat schema använder vi vårt eget: den som anropar skickar X-Signature, vilket är HMAC-SHA256-värdet av värdena i X-Webhook-*-rubrikerna, med hjälp av signeringsnyckeln.

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"}'

Så här ser ett avslag ut

Vid misslyckad autentisering returneras 401 med en JSON-kropp som anger orsaken - se Historik och felsökning för en fullständig lista över koder. Avvisade anrop visas fortfarande i Live Request Inspector medan du redigerar webhooken, så att du kan se exakt varför ett anrop avvisades.

Att byta ut hemligheten utan driftstopp

Att byta ut en hemlig nyckel i ett steg innebär att alla förfrågningar som är signerade med den gamla nyckeln misslyckas tills avsändaren hunnit anpassa sig. Genom att rotera den hemliga nyckeln via webhooken undviks detta: den innehåller en andra giltig hemlig nyckel som accepteras parallellt med den huvudsakliga, både för det statiska tokenet och för alla signaturscheman.

1. Ange den nya koden i fältet ”Andra giltiga koden” och spara. Båda koderna godkänns nu.
2. Ställ in avsändaren på den nya hemligheten.
3. Klicka på ”Promote”, vilket flyttar den till huvudfältet och rensar det andra fältet, och spara.

Ingen begäran avvisas i något skede. Den andra hemligheten lagras på exakt samma sätt som den huvudsakliga och returneras aldrig av API:et - endast information om huruvida en sådan är inställd.

Att bevara hemligheten

• Token returneras aldrig av vårt REST-API eller vår MCP-server, oavsett åtkomstnivå - de Ange endast om någon av dem är inställd. Se Utvecklings-API och MCP.
• Den är krypterad i lagring.
• När du roterar den träder ändringen i kraft omedelbart, så använd istället den andra hemliga sekvensen ovan istället för och därmed skriva över huvudfältet.
• Den sparade anropshistoriken döljer autentiseringshuvudet, Basic-inloggningsuppgifterna och URL-tokenet, Så en skärmdump av historiken avslöjar inte din hemlighet.

Att begränsa det ytterligare

Autentisering bevisar att den som ringer känner till hemligheten. IP-tillåtelselistor begränsar varifrån ett anrop får komma och kan kombineras med vilket som helst av lägena ovan.