Behöver ert företag hjälp med att implementera AI? Kontakta oss och få prisoffert här →
AI Skolan
januari 22, 2026

Google Cloud Run + Google Cloud Console: färre auth-fel

Rickard Andersson Partner, Nodenordic.se

Ditt Cloud Run-anrop fungerar. Sedan gör det inte det. Ett saknat id_token, en utgången token som ligger gömd i ett workflow-steg, eller en ”snabbfix” som kopierats in i fem olika automationer. Plötsligt kör du om jobb, plöjer loggar och spelar upp requests manuellt.

Det här Cloud Run auth-problemet slår först mot automationsbyggare, helt ärligt. Men growth-team som kör backend-jobb och byråoperatörer som levererar kund-workflows känner samma smärta: auth-fel som skapar omarbete. Utfallet är enkelt. Du återanvänder giltiga tokens och skapar bara nya när det behövs.

Det här workflowet ger dig ett litet, återanvändbart ”auth-lager” som du kan anropa från valfritt n8n-flöde. Du får se hur det minskar misslyckade anrop, vad det returnerar och var du kopplar in det i dina egna automationer.

Så fungerar den här automationen

Se hur den här löser problemet:

n8n Workflow Template: Google Cloud Run + Google Cloud Console: färre auth-fel

Utmaningen: Cloud Run-anrop misslyckas eftersom tokens inte återanvänds

När du anropar en privat Google Cloud Run-tjänst är autentisering inte valfritt. I praktiken slutar team med att klistra in tokenlogik i varje workflow, eller så skickar de runt ett id_token utan att kontrollera om det fortfarande är giltigt. Det fungerar… tills det går ut mitt i körningen, eller tills ett schemalagt jobb startar kallt utan någon token alls. Då får du en 401/403, workflowet stannar och du sitter och försöker igen med uppgifter som borde vara tråkigt pålitliga. Tidskostnaden är dålig, men den mentala belastningen är värre eftersom du aldrig riktigt litar på dina automationer.

Det summerar snabbt. Här är var det fallerar i verkliga workflows.

  • Du slutar med att generera en ny token för varje request, vilket gör körningar långsammare och ökar antalet rörliga delar du måste underhålla.
  • Tokens lagras på fel ställe (inne i noder eller kopierade in i uttryck), så credential-hygien blir en konstant ”läckte vi något?”-oro.
  • En token kan se ”närvarande” ut men ändå vara i praktiken död, så ditt workflow fallerar halvvägs genom en batch och du ombearbetar poster manuellt.
  • Varje ny Cloud Run-endpoint blir ett litet auth-projekt, så det tar längre tid än det borde att leverera automationer.

Lösningen: en återanvändbar tokenkontroll + signerande sub-workflow

Det här n8n-sub-workflowet ligger framför dina Cloud Run-anrop och fungerar som en liten token-”butler”. Du anropar det med en service_url, en valfri service_path och eventuellt en tidigare id_token. Först kontrollerar det om en token skickades in. Om ja avkodar workflowet token-payloaden och verifierar utgångstiden med en inbyggd buffert (cirka fem minuter), så att du inte startar arbete med en token som snart dör. Om token fortfarande är bra återanvänds den. Om inte signerar workflowet en kortlivad JWT med din Google Cloud service accounts privata nyckel, växlar den JWT:en via Googles token-endpoint och returnerar ett färskt id_token. Samma indata, samma utdata, pålitlig auth.

Workflowet startar när din huvudautomation anropar det via Execute Workflow. Det slår ihop inkommande data med konfigurerade variabler som client_email och token_uri. Sedan återanvänder det antingen befintligt id_token eller genererar ett nytt och skickar tillbaka det tillsammans med URL-detaljerna så att du kan träffa din privata Cloud Run-endpoint direkt.

Vad som förändras: före vs. efter

Praktisk effekt i verkligheten

Säg att ditt team kör 20 Cloud Run-anrop per dag över 4 automationer. Om varje flöde lägger ens 5 minuter på token-setup, omkörningar eller ”varför är det här 401?”-kontroller blir det ungefär 100 minuter friktion per dag. Med det här sub-workflowet skickar du service_url och återanvänder ett fortfarande giltigt id_token, så din manuella tid sjunker till nära noll efter uppsättning. Token-växlingen sker bara när det faktiskt behövs, vilket innebär färre trasiga körningar och färre omkörningar.

Krav

  • n8n-instans (prova n8n Cloud gratis)
  • Alternativ för self-hosting om du föredrar det (Hostinger fungerar bra)
  • Google Cloud Console för att skapa och hantera ett service account.
  • Google Cloud Run med en privat tjänst du vill anropa.
  • Privat nyckel för service account (PEM/JWT) (ladda ner den från service account-sektionen ”Keys” i Google Cloud Console).

Kunskapsnivå: Medel. Du klistrar in värden som client_email och lägger till en service account-nyckel som ett n8n Credential.

Behöver du hjälp att implementera detta? Prata med en automationsexpert (gratis 15-minuters konsultation).

Workflow-flödet

Ditt huvud-workflow anropar sub-workflowet. Det är byggt för att triggas via n8n:s Execute Workflow och skicka in service_url, valfri service_path och eventuellt ett befintligt id_token.

Konfiguration och indata slås ihop. Workflowet sätter variabler som client_email och bekräftar Googles token-endpoint (https://oauth2.googleapis.com/token), och slår sedan ihop det med din inkommande kontext så att varje körning har det som behövs.

Token valideras eller byts ut. Om ett id_token finns avkodar det payloaden och kontrollerar utgångstid med en fem minuters säkerhetsbuffert. Om den fortfarande är giltig extraheras token och återanvänds. Om den saknas eller snart går ut skapar workflowet en signerad JWT med din service accounts privata nyckel och växlar den till ett nytt id_token via en HTTP-request till Google.

Strukturerade utdata skickas tillbaka till anroparen. Du får id_token, service_url och service_path, redo att sättas i headers för din Cloud Run-request och anropa den privata endpointen.

Du kan enkelt justera utgångsbufferten eller lägga till målgruppsspecifik logik för att matcha hur din Cloud Run-tjänst är konfigurerad. Se hela implementationsguiden nedan för anpassningsalternativ.

Steg-för-steg-guide för implementering

Steg 1: Konfigurera Workflow Input Trigger

Det här arbetsflödet startar när ett annat arbetsflöde anropar det och skickar med de obligatoriska indatafälten för tokenhantering.

  1. Lägg till och konfigurera Workflow Input Trigger med tre inputs: id_token, service_url och service_path.
  2. Bekräfta exekveringsflödet: Workflow Input Trigger skickar utdata parallellt till både Merge Input Context och Set Config Variables.
  3. Behåll den klistrade notisen Flowpast Branding för dokumentationssammanhang (valfritt, ingen konfiguration krävs).

Steg 2: Anslut konfiguration och slå samman indatakontext

Förbered tjänstinställningar och slå samman dem med inkommande indata före validering och tokenhantering.

  1. I Set Config Variables ställer ni in Moderaw.
  2. Ställ in jsonOutput till ={ "service_url": "{{ $json.service_url }}", "client_email": "_____INSERT_____", "token_uri": "https://oauth2.googleapis.com/token" }.
  3. I Merge Input Context ställer ni in Modecombine och Combine BycombineAll.

⚠️ Vanlig fallgrop: Ersätt _____INSERT_____ i Set Config Variables med er faktiska klient-e-postadress, annars kommer steget för JWT-signering att misslyckas.

Steg 3: Sätt upp kontroll av token och JWT-validering

Det här steget kontrollerar om en token finns, avkodar den och avgör om en uppdatering krävs.

  1. I Token Presence Check säkerställer ni att villkoret kontrollerar att id_token finns med ={{ $json.id_token }}.
  2. Konfigurera Decode JWT Payload med Operation satt till decode och Token satt till ={{ $json.id_token }}.
  3. Inloggningsuppgifter krävs: Anslut era jwtAuth-credentials i Decode JWT Payload.
  4. I Check Token Expiry validerar ni utgångstid med ={{ ($json.payload.exp * 1000) - 300000}} jämfört med ={{ Date.now() }}.

Steg 4: Konfigurera tokenuppdatering och bygg utdata

Om token saknas eller har gått ut skapar arbetsflödet en signerad JWT, växlar den och bygger ihop utdatapayloaden.

  1. I Create Signed JWT ställer ni in Use JSONtrue och Claims JSON={ "iss": "{{ $json.client_email }}", "sub": "{{ $json.client_email }}", "aud": "{{ $json.token_uri }}", "iat": {{ Math.floor(Date.now() / 1000) }}, "exp": {{ Math.floor(Date.now() / 1000) + 3600 }}, "target_audience": "{{ $json.service_url }}" }.
  2. Inloggningsuppgifter krävs: Anslut era jwtAuth-credentials i Create Signed JWT.
  3. I Token Exchange Call ställer ni in URL till ={{ $('Set Config Variables').item.json.token_uri }} och Method till POST.
  4. Ställ in Content Typeform-urlencoded, Send Bodytrue och Body=grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&assertion={{ $json.token }}.
  5. I Extract Token Field mappar ni id_token till ={{ $('Merge Input Context').item.json.id_token }} för flödet utan uppdatering.
  6. I Assemble Output Data ställer ni in fälten: id_token till ={{ $json.id_token }}, service_url till ={{ $('Merge Input Context').item.json.service_url }} och service_path till ={{ $('Merge Input Context').item.json.service_path }}.

Steg 5: Testa och aktivera ert arbetsflöde

Verifiera att både uppdateringsvägen och vägen utan uppdatering ger korrekt utdata.

  1. Klicka på Execute Workflow och ange exempelindata för id_token, service_url och service_path.
  2. Verifiera att en giltig token som inte har gått ut routas via Extract Token Field till Assemble Output Data.
  3. Verifiera att en token som saknas eller har gått ut routas via Create Signed JWTToken Exchange CallAssemble Output Data.
  4. Bekräfta att utdatan innehåller värden för id_token, service_url och service_path.
  5. Slå på arbetsflödet med reglaget Active för att aktivera användning i produktion.
🔒

Lås upp fullständig steg-för-steg-guide

Få den kompletta implementeringsguiden + nedladdningsbar mall

Se upp med

  • Google Cloud service account-nycklar roteras eller tas bort. Om token-växling plötsligt misslyckas, kontrollera service account-sidan ”Keys” i Google Cloud Console och uppdatera sedan ditt n8n Credential.
  • Om du använder Wait-noder eller extern rendering varierar processtiderna. Öka väntetiden om nedströms noder fallerar på tomma svar.
  • Standardprompter i AI-noder är generiska. Lägg in din tonalitet tidigt, annars kommer du att redigera utdata för alltid.

Vanliga frågor

Hur snabbt kan jag implementera den här Cloud Run auth-automationen?

Cirka 30 minuter om ditt service account är klart.

Kan icke-tekniska team implementera den här återanvändningen av auth-token?

Ja, men du vill ha någon som är bekväm i Google Cloud Console för att skapa service account-nyckeln. Efter det handlar det mest om att kopiera värden till n8n och testa en endpoint.

Är n8n gratis att använda för det här Cloud Run auth-workflowet?

Ja. n8n har ett gratis alternativ för self-hosting och en gratis provperiod på n8n Cloud. Cloud-planer startar på 20 USD/månad för högre volym. Du behöver också räkna in Google Cloud-användning (Cloud Run-requests kostar oftast småpengar och token-växling är normalt sett försumbar).

Var kan jag hosta n8n för att köra den här automationen?

Två alternativ: n8n Cloud (hanterat, enklast att komma igång) eller self-hosting på en VPS. För self-hosting är Hostinger VPS prisvärd och hanterar n8n bra. Self-hosting ger dig obegränsat antal körningar men kräver grundläggande serverhantering.

Hur anpassar jag den här Cloud Run auth-lösningen till mina specifika utmaningar?

Det kan du. De flesta anpassningar sker i delen ”Set Config Variables” (för att ändra client_email eller token-endpoint), och i utgångskontrollen (för att justera femminutersbufferten). Om du anropar flera Cloud Run-tjänster skickar du in olika service_url per request och behåller auth-logiken identisk. Vissa team lägger också till ett ”audience”-fält för att matcha en striktare Cloud Run/IAM-konfiguration.

Varför misslyckas min Google Cloud Run-anslutning i det här workflowet?

Oftast är det ett problem med service account-nyckeln, inte Cloud Run i sig. Generera om nyckeln, bekräfta att client_email matchar och säkerställ att token-endpointen fortfarande är https://oauth2.googleapis.com/token. Kontrollera också att din Cloud Run-tjänst faktiskt kräver en identity token för rätt audience. Om du återanvänder tokens över långa batchkörningar kan en för liten utgångsbuffert fortfarande ställa till det.

Vad är kapaciteten för den här Cloud Run auth-lösningen?

Den är lättviktig, så kapaciteten handlar mest om din n8n-plan och server. På n8n Cloud Starter kan du köra ett bra antal månatliga exekveringar, och högre planer klarar mer. Om du self-hostar finns inget tak för antalet exekveringar (det beror på storleken på din VPS och hur många workflows som kör samtidigt). I praktiken innebär tokenåteranvändning att du vanligtvis växlar långt färre tokens än ”en per request”, vilket håller det stabilt under belastning.

Är den här Cloud Run auth-automationen bättre än att använda Zapier eller Make?

Ofta, ja. Det här workflowet bygger på tokenavkodning, villkorslogik och att signera JWT:er med en service account-nyckel, och n8n är helt enkelt smidigare för det utan krångliga workarounds. Zapier och Make kan anropa webhooks och API:er, men mer komplex auth-logik blir snabbt stökig, och du är oftast låst till deras prissättning per körning. Om du vill self-hosta för obegränsade körningar är det en annan stor n8n-fördel. Samtidigt: om din automation bara är två steg och publika endpoints räcker kan Zapier eller Make vara nog. Prata med en automationsexpert om du väger avvägningar.

När detta väl är på plats blir Cloud Run-auth tråkigt igen, vilket är exakt vad du vill. Dina workflows kör, återanvänder tokens säkert och slutar fallera av skäl som inte har något med din faktiska affärslogik att göra.

Kontakta oss

Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.

×

Använd mall

Få direkt tillgång till denna n8n-arbetsflödes JSON-fil

Launch login modal Launch register modal