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

Postman + Airtable: JWT-inloggning som bara fungerar

Rickard Andersson Partner, Nodenordic.se

Ditt inloggningsflöde “fungerar” tills det inte gör det. En token går ut vid fel tillfälle, uppdatering misslyckas utan att märkas, användare blir utloggade och du hamnar i felsökning av autentisering i stället för att bygga din produkt. Så blir små buggar till stora supporttrådar.

Den här Postman Airtable JWT-automationen är för utvecklaren som vill få ut en MVP, byrån som bygger interna verktyg åt kunder, och den produktdrivna grundaren som ärligt talat är trött på att tejpa ihop autentisering. Du får en produktionsredo uppsättning endpoints för registrering, inloggning, verifiering och uppdatering, utan att behöva sätta upp en hel autentiseringstjänst.

Du får se hur workflowet hanterar säker lösenordshashning, skapande av JWT, lagring av refresh token och förutsägbara felrespons. Sedan vet du exakt vad du behöver för att köra det och hur du anpassar det till din app.

Så fungerar den här automationen

Hela n8n-workflowet, från trigger till slutligt resultat:

n8n Workflow Template: Postman + Airtable: JWT-inloggning som bara fungerar

Problemet: autentiseringens “edge cases” blir ditt heltidsjobb

Autentisering verkar enkel ända tills du släpper den. Lösenord kräver korrekt hashning och salt, tokens behöver livslängder, uppdatering kräver säker lagring och felmeddelanden måste undvika att läcka detaljer. Samtidigt försöker du bygga funktioner som användare faktiskt betalar för. Resultatet blir ofta ett halvt byggt autentiseringslager som fungerar i happy-path-testning men faller sönder i verklig användning: flera enheter, utgångna sessioner och retries. Det är inte komplexiteten i en enskild bugg. Det är hopningen.

Friktionen växer snabbt. Här brukar team fastna.

  • Du slutar med att underhålla egna inloggnings-endpoints som beter sig olika i webb, mobil och interna verktyg.
  • Refresh tokens lagras i klartext (eller lagras inte alls), vilket gör “logga ut överallt” omöjligt.
  • Tokenverifiering blir inkonsekvent, så skyddade routes fallerar på sätt som är svåra att återskapa.
  • Du lägger cirka 2 timmar i veckan på felsökning av autentisering och omtestning efter “små ändringar”.

Lösningen: en komplett JWT-auth-backend i n8n

Det här workflowet gör n8n till en fullständig autentiseringsbackend med fyra strukturerade endpoints: register, login, verify-token och refresh. En användare registrerar sig via en webhook, workflowet validerar indata, kontrollerar om e-post eller användarnamn redan är upptaget och hash:ar sedan lösenordet med SHA-512 och ett unikt salt innan användaren sparas. Vid inloggning hämtar det användarposten, räknar om hash:en för det angivna lösenordet och genererar först därefter två JWT: en kortlivad access token (cirka 15 minuter) och en långlivad refresh token (cirka 7 dagar). För uppdatering validerar workflowet refresh-JWT-signaturen, hash:ar refresh token innan uppslag, bekräftar att den inte har gått ut och utfärdar en ny access token utan att tvinga fram ny inloggning.

Workflowet startar med webhooks som din app kan anropa från valfri frontend. I mitten hanterar krypto- och kodenoder hashning, signering och validering. Till sist returneras svar direkt via “Respond to Webhook”, så Postman-tester och riktiga klienter alltid får konsekvent JSON.

Vad du får: automation vs. resultat

Exempel: så här ser det ut

Säg att du bygger en liten SaaS och behöver fyra endpoints: register, login, verify, refresh. Manuellt är det oftast en dags jobb med att koppla routes, hashning, tokensignering, lagring för refresh, plus en dag till med “varför fallerar det här på mobilen”. Med det här workflowet konfigurerar du secrets och Data Tables en gång, och testar sedan alla fyra anrop i Postman på cirka 30 minuter. Tokens utfärdas och verifieras på samma sätt varje gång, vilket sparar dig ett par timmar omtestning vid varje release.

Det här behöver du

  • n8n-instans (testa n8n Cloud gratis)
  • Alternativ för self-hosting om du föredrar det (Hostinger fungerar bra)
  • Postman för att testa auth-endpoints
  • n8n Data Tables för att lagra användare och refresh tokens
  • Access- + refresh-secrets (generera med Node crypto-kommando)

Kompetensnivå: Medel. Du klistrar in webhook-URL:er i Postman, sätter secrets säkert och mappar ett par request/response-fält.

Vill du inte sätta upp detta själv? Prata med en automationsexpert (gratis 15-minuters konsultation).

Så fungerar det

Ett webhook-anrop träffar en av dina auth-endpoints. n8n exponerar separata webhooks för registrering, inloggning, verify-token och refresh, så din frontend kan anropa dem som ett vanligt REST API.

Indata valideras och normaliseras. Workflowet tolkar inkommande JSON, kontrollerar obligatoriska fält och svarar med ett säkert svar i stil med “bad request” när något saknas (utan att dela för mycket).

Krypto- och tokenlogik körs i mitten. Lösenord saltas och hash:as, JWT-payloads byggs och signaturer valideras med dina konfigurerade secrets. Refresh tokens hash:as innan de lagras eller slås upp, vilket innebär att en läckt tabell fortfarande är betydligt mindre användbar.

Data Tables lagrar källan till sanningen. Användarposter hamnar i en users-tabell, refresh tokens hamnar i en refresh_tokens-tabell med en utgångstidsstämpel, och workflowet returnerar tokens (eller fel) via “Respond to Webhook”.

Du kan enkelt justera token-livslängder för att matcha din risknivå utifrån dina behov. Se den fullständiga implementationsguiden nedan för alternativ för anpassning.

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

Steg 1: konfigurera webhook-triggers

Sätt upp de tre publika ingångarna för registrering, inloggning och tokenverifiering så att externa klienter kan anropa workflowet.

  1. Öppna Incoming Registration Hook och ställ in Path till register-user och HTTP Method till POST.
  2. Öppna Login Webhook Trigger och ställ in Path till login och HTTP Method till POST.
  3. Öppna Access Token Webhook och ställ in Path till verify-token och HTTP Method till POST.
  4. Öppna Refresh Token Webhook och ställ in Path till refresh och HTTP Method till POST.
  5. Säkerställ att varje webhook använder Response Mode inställt på responseNode så att svaren returneras av svarsnoderna.

Steg 2: koppla datalagring för användar- och tokentabeller

Detta workflow lagrar användare och refresh tokens i Data Tables. Konfigurera tabell-ID:n och lägg till autentiseringsuppgifter för alla Data Table-noder.

  1. I Fetch User by Username, ställ in Data Table till er användartabell och behåll Operation som get med Limit 1.
  2. I Fetch User by Email och Fetch User Record, välj samma användartabell och säkerställ att filtren använder {{$json.email}}.
  3. I Insert User Record, välj användartabellen och mappa kolumner till {{$json.email}}, {{$json.username}} och {{$json.password_hash}}.
  4. I Update User Refresh Field, ställ in användartabellen och uppdatera refresh_token med {{$json.refreshToken}}.
  5. I Upsert Refresh Token och Check Refresh Exists, välj er refresh token-tabell och bekräfta filter för {{$json.token_hash}} och {{$json.userId}}.
  6. Autentiseringsuppgifter krävs: Koppla era Data Table-autentiseringsuppgifter till alla dataTable-noder (Fetch User by Username, Fetch User by Email, Fetch User Record, Insert User Record, Update User Refresh Field, Upsert Refresh Token, Check Refresh Exists).

⚠️ Vanlig fallgrop: Data Table-noderna använder [YOUR_ID]. Ersätt varje Data Table-ID med era faktiska tabell-ID:n, annars kommer läsningar/skrivningar att misslyckas.

Steg 3: konfigurera tolkning och validering för registrering

Dessa noder tolkar registreringspayloaden och genomför grundläggande validering innan användaren skapas.

  1. I Parse Signup Request, verifiera att fältmappningar för email, username och password är satta till {{$json.body.email}}, {{$json.body.username}} och {{$json.body.password}}.
  2. Granska Validate Signup Request för att säkerställa att den kräver password.length >= 8 och konverterar e-postadresser till gemener som förväntat.
  3. Bekräfta routingen: Parse Signup Request → Validate Signup Request → Fetch User by Username → Check Username Free.
  4. Säkerställ att avvisningsvägar svarar med Invalid Signup Reply och Username Taken Reply.

Steg 4: bygg hashing-pipelinen för registrering

Denna sekvens skapar ett salt, hash:ar lösenordet och skriver den nya användarposten.

  1. Från Check Email Free, bekräfta att true-grenen går till Create Random Salt och false-grenen till Email Taken Reply.
  2. I Create Random Salt, behåll Action inställt på generate, Encoding Type på hex och Data Property Name på salt.
  3. Säkerställ att Combine Password Salt använder den inbyggda koden för att sätta passwordWithSalt och att Hash User Password sedan hash:ar {{$json.passwordWithSalt}} med Type SHA512.
  4. Verifiera att Map User Payload output:ar password_hash i formatet salt:hash.
  5. Koppla Map User Payload → Insert User Record → Registration Success Reply, och låt Registration Error Reply ligga på felvägen.

Tips: Behåll samma hash-algoritm (SHA512) genom hela registrering och inloggning för att undvika avvikelser i Confirm Password Hash.

Steg 5: konfigurera tolkning av inloggning och verifiering av användare

Inloggningsflödet tolkar inloggningsuppgifter, validerar indata, hämtar användaren och jämför lösenordshashen.

  1. I Parse Login Webhook, behåll mappningar till {{$json.body.email}} och {{$json.body.password}}.
  2. I Set Auth Secrets, ställ in ACCESS_SECRET och REFRESH_SECRET till era signeringsnycklar (lämna dem inte tomma).
  3. Bekräfta att Validate Login Input routar success till Fetch User Record och failure till Bad Request Reply.
  4. Säkerställ att Check User Exists routar success till Derive Salt and Hash och failure till User Missing Reply.
  5. Verifiera Derive Salt and Hash → Hash Input Secret (med {{$json.passwordWithSalt}}) → Confirm Password Hash.

⚠️ Vanlig fallgrop: Om ni glömmer att sätta secrets i Set Auth Secrets kommer HMAC-signering i Sign Access JWT och Sign Refresh JWT att skapa ogiltiga tokens.

Steg 6: generera och lagra JWT-tokens

Efter bekräftat lösenord skapas och lagras tokens. Denna del innehåller en parallell gren.

  1. Låt Create JWT Payloads vara som den är så att den bygger accessSignatureInput och refreshSignatureInput.
  2. Create JWT Payloads output:ar till både Sign Access JWT och Sign Refresh JWT parallellt.
  3. Verifiera att Sign Access JWT använder {{$json.accessSignatureInput}} och {{$('Set Auth Secrets').item.json.ACCESS_SECRET}}.
  4. Verifiera att Sign Refresh JWT använder {{$json.refreshSignatureInput}} och {{$('Set Auth Secrets').item.json.REFRESH_SECRET}}.
  5. Säkerställ att Combine JWT Outputs slår ihop med Fields to Match inställt på userId och skickar vidare till Assemble JWT Tokens.
  6. Bekräfta Assemble JWT Tokens → Hash Refresh Token Save → Prepare Token Record.
  7. Prepare Token Record output:ar till både Update User Refresh Field och Upsert Refresh Token parallellt.
  8. Behåll merge-grenväljaren: Update User Refresh Field och Upsert Refresh Token → Select Merge Output → Login Success Reply.

Steg 7: konfigurera flöde för verifiering av access token

Denna route validerar access tokens och returnerar lyckat eller misslyckat resultat.

  1. Verifiera att Parse Verify Token Hook mappar access_token till {{$json.body.access_token}}.
  2. I Set Verify Secrets, ställ in ACCESS_SECRET och REFRESH_SECRET så att de matchar secrets i inloggningsflödet.
  3. Säkerställ Decode Access JWT → Set Verify Secrets → Validate HMAC Signature → Compare Token Signatures.
  4. Bekräfta att success routas till Access Token Valid Reply och failure till Access Token Invalid Reply.

Steg 8: konfigurera flöde för rotation av refresh token

Detta flöde validerar refresh tokens och utfärdar en ny access token.

  1. I Parse Refresh Hook, mappa refresh_token till {{$json.body.refresh_token}}.
  2. Sätt secrets i Set Refresh Secrets så att de matchar inloggningsflödet.
  3. Bekräfta vägen: Decode Refresh JWT → Validate Refresh Signature → Compare Refresh Sign → Hash Refresh Lookup → Check Refresh Exists → Refresh Token Valid Check.
  4. Säkerställ att Refresh Token Valid Check routar success till Build Access Payload och failure till Session Expired Reply.
  5. Verifiera Build Access Payload → Sign New Access JWT (med {{$('Set Refresh Secrets').item.json.ACCESS_SECRET}}) → Assemble Access JWT → Respond New Access Token.

Steg 9: lägg till svar för felhantering

Flera noder är konfigurerade att fortsätta vid fel och returnera tydliga svar för ogiltiga förfrågningar.

  1. Behåll noderna för felsvar kopplade: Bad Request Reply, Invalid Login Reply, User Missing Reply, Email Taken Reply, Username Taken Reply, Invalid Signup Reply, Session Expired Reply och Registration Error Reply.
  2. Bekräfta att routing vid fel i Validate Signup Request, Validate Login Input, Confirm Password Hash, Compare Token Signatures och Insert User Record fortsatt är aktiverad (Continue On Fail).

Tips: Håll felsvar konsekventa för att förenkla hantering på klientsidan. Dessa noder returnerar redan strukturerad JSON för varje feltyp.

Steg 10: testa och aktivera ert workflow

Kör varje webhook-sökväg med exempelpayloads för att verifiera hela autentiseringslivscykeln.

  1. Klicka på Test Workflow och skicka en POST till /register-user med {"email":"[email protected]","username":"testuser","password":"password123"}.
  2. Skicka en POST till /login med samma inloggningsuppgifter och bekräfta att Login Success Reply returnerar accessToken och refreshToken.
  3. Skicka en POST till /verify-token med {"access_token":""} och bekräfta att Access Token Valid Reply returnerar lyckat resultat.
  4. Skicka en POST till /refresh med {"refresh_token":""} och bekräfta att Respond New Access Token returnerar en ny access token.
  5. När testerna lyckas, växla workflowet till Active för användning i produktion.
🔒

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

Få den kompletta implementeringsguiden + nedladdningsbar mall

Vanliga fallgropar

  • Behörigheter för n8n Data Tables kan ställa till det. Om inserts eller uppslag misslyckas, kontrollera vald tabell i varje Data Table-nod och bekräfta att funktionen är aktiverad i din workspace.
  • Om du använder Wait-noder eller extern rendering varierar processtiderna. Öka väntetiden om noder längre fram misslyckas på grund av tomma svar.
  • Standardprompter i AI-noder är generiska. Lägg in er tonalitet tidigt, annars kommer du att redigera output för alltid.

Relaterade workflows

Om du bygger ett lättviktigt “begär en token”-flöde för interna team passar Airtable token requests, delivered to Slack clean bra ihop med den här auth-backenden, så att förfrågningar och godkännanden inte hamnar i någons inkorg.

När du vill ha en enklare startpunkt som bara fokuserar på att utfärda JWT:er vid inloggning är Airtable login that issues JWT tokens for your app ett bra jämförelse-workflow innan du går vidare med registrering + refresh.

För team som gör onboarding och behörighetsprovisionering samtidigt hjälper Zoom + Google Sheets: simple user onboarding till att automatisera delen “skapa användare, skicka detaljer, följ status” medan det här workflowet hanterar inloggningssäkerheten.

Behöver du långlivade tokens som inte slumpmässigt skapar fel i integrationer längre fram? Facebook + Google Sheets: tokens stay valid är användbart när ditt “auth-problem” egentligen är token-uppdatering mot tredjeparts-API:er, inte bara användarsessioner.

Slutligen, om du driftsätter webhooks och tjänster i Googles ekosystem är Google Cloud Run + Google Cloud Console: fewer auth fails ett stabilt nästa steg för att hårdna driftsättningar och minska autentiseringsrelaterade fel i produktion.


Snabbreferens:

Vanliga frågor

Hur lång tid tar det att sätta upp den här Postman Airtable JWT-automationen?

Cirka 45 minuter om dina Data Tables är klara.

Behöver jag kunna koda för att automatisera JWT-inloggningstestning med Postman + Airtable?

Nej. Du konfigurerar främst credentials, secrets och request bodies i Postman. Du kan fortfarande anpassa kodenoder senare om du vill ha mer kontroll.

Är n8n gratis att använda för det här Postman Airtable JWT-workflowet?

Ja. n8n har ett gratis self-hosted-alternativ och en gratis provperiod på n8n Cloud. Cloud-planer börjar på 20 USD/månad för högre volymer. Du behöver också räkna in infrastrukturkostnader (en liten VPS räcker ofta).

Var kan jag hosta n8n för att köra den här Postman Airtable JWT-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ärt och hanterar n8n bra. Self-hosting ger dig obegränsat antal körningar men kräver grundläggande serverhantering.

Kan jag anpassa det här Postman Airtable JWT-workflowet för rotation av refresh token?

Ja, men planera noggrant. Du kan bygga ut refresh-flödet genom att uppdatera valideringen av refresh token och skrivstegen i Data Table (”Upsert Refresh Token” och relaterad hash-/uppslagslogik) så att varje uppdatering utfärdar en ny refresh token och ogiltigförklarar den gamla. Vanliga anpassningar är att ändra token-livslängder, lägga till användarroller i JWT-payloaden och kräva starkare lösenordsregler i valideringen vid registrering.

Varför misslyckas min Airtable-anslutning i den här Postman Airtable JWT-automationen?

Oftast är det fel tabell som valts i en Data Table-nod, eller så är Data Tables-funktionen inte aktiverad i den n8n-workspace:en. Dubbelkolla tabellmappningarna för “users” och “refresh_tokens”, och kör sedan ett enskilt webhook-test från Postman igen. Om det fortfarande misslyckas, rotera credential och bekräfta att din n8n-instans kan persistera data (vissa flyktiga deploymenter återställs).

Hur många inloggningar klarar den här Postman Airtable JWT-automationen?

I de flesta uppsättningar klarar den gott och väl en MVP: hundratals inloggningar per dag är typiskt. Om du self-hostar är den främsta begränsningen din server och hur snabbt dina Data Tables svarar.

Är den här Postman Airtable JWT-automationen bättre än att använda Zapier eller Make?

För auth-flöden: ja, i de flesta fall. Du behöver kryptooperationer, grenlogik och konsekventa webhook-svar, och n8n är helt enkelt byggt för den typen av “backend-liknande” workflow. Zapier och Make kan kännas enklare i början, men de blir klumpiga för säker tokenhantering och du kommer att slå i begränsningar när du lägger till verifiering och refresh. Self-hosting är också viktigt om du vill ha förutsägbara kostnader. Om du är osäker: prata med en automationsexpert och rimlighetskontrollera upplägget innan du släpper det.

Autentisering är den typen av sak du vill sätta upp en gång och sluta tänka på. Det här workflowet tar dig dit, med färre överraskningar när riktiga användare dyker upp.

Kontakta oss

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

Våra tjänster Om Node Nordic
×

Använd mall

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

Kopiera och importera JSON-arbetsflödet i ditt n8n-arbetsflöde

Få prisoffert redan idag!
Få prisoffert redan idag!

Berätta vad ni behöver hjälp med så hör vi av oss inom en arbetsdag!

Få prisoffert redan idag!
Få prisoffert redan idag!

Berätta vad ni behöver hjälp med så hör vi av oss inom en arbetsdag!