Autentisering

Alle som kjenner en webhook-URL, kan sende en forespørsel til den, så det er autentisering som hindrer at en fremmed setter i gang Shopify Flow-arbeidsflytene dine. Du angir dette for hver enkelt webhook, under delen Sikkerhet for den aktuelle webhooken.

De tre metodene

Metode	Hvordan den som ringer identifiserer seg	Bruk den når
Ingen	Ingenting	Kun til testing - aldri i produksjon
Statisk token	En fast hemmelighet i en forespørselsoverskrift	Nesten alle integrasjoner (n8n, Make, Zapier, din egen kode)
HMAC SHA-256	En signatur beregnet ut fra forespørselen og en delt hemmelig nøkkel	Avsenderen signerer sine webhooks (Stripe, GitHub, Slack, …)

Statisk token

Trykk på «Generer»-knappen i webhooken for å få et sterkt tilfeldig token, eller lim inn ditt eget. Den som sender forespørselen, sender det i en header:

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

Endre navnet på overskriften

Noen systemer kan bare sende en overskrift som de allerede bruker. Angi navnet på Auth-overskriften i «Avanserte innstillinger», så leser vi tokenet fra den overskriften i stedet for X-Api-Key:

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

Det skilles ikke mellom store og små bokstaver i navnene på overskrifter. Reserverte navn avvises - Host, Authorization, Cookie, X-Forwarded-*, X-Webhook-*, CF-* og lignende. Disse settes eller omskrives av proxyservere og CDN-er, så et token som leses fra en slik kilde, vil kunne kontrolleres av en angriper.

Hvor tokenet beveger seg

Ikke alle avsendere kan legge til en vilkårlig overskrift. Hvordan sender avsenderen tokenet? Under fanen «Webhook» finnes det fire muligheter:

Valg	Avsenderen sender	Bruk den når
I en tilpasset overskrift	X-Api-Key: <token> eller det overskriftsnavnet du velger	Standardinnstillingen, og slik de fleste integrasjoner fungerer
Som et «Bearer»-token	Authorization: Bearer <token>	Verktøyet har et felt for «Bearer»- eller «API-token»
Som brukernavn og passord	HTTP Basic, med et brukernavn du selv velger og tokenet som passord	Verktøyet støtter kun grunnleggende autentisering
I nettadressen	?token=<token> eller det parameternavnet du velger	Avsenderen kan bare hente en vanlig URL og kan ikke angi overskrifter

Authorization er bevisst holdt som et reservert navn på en egendefinert header: «Bearer» og «Basic» er de støttede måtene å bruke den på, og begge håndteres automatisk for deg. En 401-feil for disse to inneholder også en WWW-Authenticate-header, fordi flere HTTP-klienter kun sender påloggingsopplysninger etter å ha blitt bedt om det.

URL-alternativet er det svakeste av de fire - URL-er havner i logger, henvisningskilder og nettleserhistorikken - så bruk det bare når avsenderen ikke gir deg noe annet valg. Appen viser den ferdige URL-en med tokenet inkludert, og skjuler denne parameteren overalt der den lagrer forespørselen.

HMAC SHA-256

Avsenderen beregner en signatur for forespørselen ved hjelp av en delt hemmelig nøkkel; vi beregner den på nytt og sammenligner. En lekket forespørsel kan ikke gjentas med endret innhold, fordi selve forespørselen ikke lenger stemmer overens med signaturen.

Forhåndsinnstillinger for leverandører

Velg avsender under Signaturleverandør, så verifiserer vi i henhold til den aktuelle leverandørens nøyaktige oppsett - overskriftsnavn, koding, hva som signeres og hvor lenge signaturen er gyldig. Lim inn signeringsnøkkelen fra dashbordet, så er du ferdig.

Det finnes 22 innebygde tjenester, hver med sin egen konfigurasjonsveiledning: 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 og Zendesk. Hvis din ikke er oppført, beskriv hvordan den signerer med et tilpasset oppsett.

Se Verifisering av signerte webhooks for den fullstendige listen, det tilpassede alternativet og den innebygde signaturtesteren.

Generisk HMAC

Siden det verken finnes noen forhåndsinnstilt eller tilpasset ordning, bruker vi vår egen: den som ringer sender X-Signature, som er HMAC-SHA256-krypteringen av verdiene i X-Webhook-*-overskriftene ved hjelp av signeringsnøkkelen.

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

Slik ser et avslag ut

Ved mislykket autentisering returneres 401 med en JSON-tekst som angir årsaken - se Historikk og feilsøking for den fullstendige kodelisten. Avviste forespørsler vises fortsatt i Live Request Inspector mens du redigerer webhooken, slik at du kan se nøyaktig hvorfor en forespørsel ble avvist.

Endre passordet uten driftsavbrudd

Hvis man endrer en hemmelig nøkkel i ett trinn, vil alle forespørsler som er signert med den gamle nøkkelen mislykkes inntil avsenderen har oppdatert seg. Ved å rotere den hemmelige nøkkelen i webhooken unngår man dette: den inneholder en ekstra gyldig hemmelig nøkkel som godtas ved siden av den primære, både for det statiske tokenet og for alle signaturordninger.

1. Skriv inn den nye koden i feltet Andre gyldige koder og lagre. Begge kodene godtas nå.
2. Bytt ut avsenderen med den nye hemmeligheten.
3. Trykk på Promote, noe som flytter den til hovedfeltet og tømmer det andre feltet, og lagre.

Ingen forespørsler blir avvist på noe tidspunkt. Den andre nøkkelen lagres på nøyaktig samme måte som hovednøkkelen, og returneres aldri av API-et - det oppgis kun om den er angitt.

Å holde hemmeligheten trygg

• Tokenet returneres aldri av vår REST-API eller MCP-server, uansett tilgangsnivå - de Rapporterer kun om en av dem er angitt. Se Utvikler-API og MCP.
• Den er kryptert når den er lagret.
• Når du roterer den, trer endringen i kraft umiddelbart, så bruk den andre hemmelige fremgangsmåten ovenfor i stedet for overskriver hovedfeltet.
• Den lagrede påkallingshistorikken skjuler autentiseringsoverskriften, Basic-påloggingsopplysningene og URL-tokenet, Så et skjermbilde av «Historikk» avslører ikke hemmeligheten din.

Å begrense det ytterligere

Autentisering bekrefter at den som ringer kjenner hemmeligheten. IP-tillatelseslister begrenser hvor et anrop kan komme fra, og kan kombineres med hvilken som helst av modusene ovenfor.