{"id":113,"date":"2026-06-18T16:47:17","date_gmt":"2026-06-18T16:47:17","guid":{"rendered":"https:\/\/shattered.io\/se\/2026\/06\/18\/oauth2-pkce-nodejs\/"},"modified":"2026-06-18T16:51:25","modified_gmt":"2026-06-18T16:51:25","slug":"oauth2-pkce-nodejs","status":"publish","type":"post","link":"https:\/\/shattered.io\/se\/oauth2-pkce-nodejs\/","title":{"rendered":"OAuth 2.0 med PKCE i Node.js: 12 steg, 30 min [2026]"},"content":{"rendered":"\n

OAuth 2.0 med PKCE (Proof Key for Code Exchange) \u00e4r 2026 \u00e5rs standardmetod f\u00f6r s\u00e4ker auktorisering i webbapplikationer. Den gamla implicita fl\u00f6det f\u00f6rsvann ur OAuth 2.0-specifikationen (RFC 6749)<\/a> efter att forskning visade att kodinterception-attacker kunde stj\u00e4la \u00e5tkomsttoken direkt fr\u00e5n redirect-URL:en. PKCE, definierat i RFC 7636<\/a>, l\u00f6ser det problemet med ett kryptografiskt handslag som binder auktoriseringskoden till den klient som skapade den. I den h\u00e4r guiden bygger du ett komplett OAuth 2.0 + PKCE-fl\u00f6de i Node.js och Express fr\u00e5n grunden, steg f\u00f6r steg.<\/p>\n\n\n\n

Vad \u00e4r OAuth 2.0 och PKCE?<\/h2>\n\n\n\n

OAuth 2.0 \u00e4r ett auktoriseringsramverk som l\u00e5ter en applikation beg\u00e4ra begr\u00e4nsad \u00e5tkomst till en anv\u00e4ndares konto hos en tredjepartstj\u00e4nst, utan att applikationen ser anv\u00e4ndarens l\u00f6senord. Fl\u00f6det involverar fyra parter: resurs\u00e4garen<\/strong> (anv\u00e4ndaren), klienten<\/strong> (din Node.js-app), auktoriseringsservern<\/strong> (t.ex. Google, GitHub, Okta) och resursservern<\/strong> (det API som skyddar anv\u00e4ndarens data).<\/p>\n\n\n\n

PKCE l\u00e4gger till ett extra lager ovanp\u00e5 auktoriseringskodfl\u00f6det. Utan PKCE kan en angripare som lyckas f\u00e5nga upp din auktoriseringskod, till exempel via ett elakt program p\u00e5 samma enhet eller via ett \u00f6ppet redirect, byta ut koden mot en \u00e5tkomsttoken. Med PKCE \u00e4r koden v\u00e4rdel\u00f6s utan code_verifier<\/strong>, en slumpm\u00e4ssig str\u00e4ng som bara din app k\u00e4nner till och som aldrig skickas i klartext under auktoriseringssteget.<\/p>\n\n\n\n

Fl\u00f6destyp<\/th>S\u00e4kerhetsniv\u00e5<\/th>Status 2026<\/th>Klienttyp<\/th><\/tr><\/thead>
Implicit Flow<\/td>L\u00e5g (token i URL)<\/td>F\u00f6r\u00e5ldrat, borttaget i OAuth 2.1<\/td>Public clients<\/td><\/tr>
Authorization Code<\/td>Medel (utan PKCE)<\/td>Acceptabelt f\u00f6r konfidentiella klienter<\/td>Confidential clients<\/td><\/tr>
Authorization Code + PKCE<\/td>H\u00f6g<\/td>Rekommenderat f\u00f6r alla klienttyper<\/td>Alla<\/td><\/tr>
Client Credentials<\/td>H\u00f6g (maskin-till-maskin)<\/td>Aktivt<\/td>Confidential clients<\/td><\/tr>
Device Code<\/td>Medel<\/td>Aktivt f\u00f6r IoT och CLI-appar<\/td>Enhetsbegr\u00e4nsade klienter<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

OAuth 2.1-utkastet, som kombinerar erfarenheterna fr\u00e5n RFC 6749, RFC 7636 och RFC 9700 (OAuth 2.0 Security Best Current Practice)<\/a>, kr\u00e4ver PKCE f\u00f6r alla auktoriseringskodfl\u00f6den och tar bort den implicita fl\u00f6det helt. Att implementera PKCE i dag inneb\u00e4r att du \u00e4r f\u00f6rberedd f\u00f6r den standarden n\u00e4r den formaliseras.<\/p>\n\n\n\n

Det praktiska resultatet syns i statistiken. Auktoriseringskodinterception representerade historiskt en av de vanligaste attackvektorerna mot OAuth-implementationer, och PKCE eliminerar den kategorin helt. Fr\u00e5n och med 2026 kr\u00e4ver leverant\u00f6rer som Google, GitHub, Okta och Microsoft PKCE f\u00f6r alla nya appregistreringar som anv\u00e4nder auktoriseringskodfl\u00f6det.<\/p>\n\n\n\n

Varf\u00f6r PKCE ersatte Implicit Flow<\/h2>\n\n\n\n

Det implicita fl\u00f6det returnerade \u00e5tkomsttoken direkt i redirect-URL:ens fragment (#access_token=eyJ...<\/code>). Det innebar tre allvarliga problem som l\u00e4nge var k\u00e4nda men ignorerades p\u00e5 grund av bekv\u00e4mlighet. Problemens sv\u00e5righetsgrad \u00f6kade i takt med att JavaScript-applikationer tog \u00f6ver allt mer av webbens auktoriseringslogik.<\/p>\n\n\n\n

F\u00f6r det f\u00f6rsta loggades token ofta av webbservrar, proxies och reverse proxies som bevarade hela URL:en inklusive fragmentet i sina accessloggar. En angripare med tillg\u00e5ng till serverns loggfiler fick direkt tillg\u00e5ng till aktiva \u00e5tkomsttoken utan att beh\u00f6va angripa kryptografin. F\u00f6r det andra exponerades token f\u00f6r JavaScript p\u00e5 sidan via window.location.hash<\/code>, vilket \u00f6ppnade f\u00f6r XSS-attacker. Varje JavaScript-injektion p\u00e5 sidan gav angriparen omedelbar tillg\u00e5ng till token. F\u00f6r det tredje gick det inte att verifiera att r\u00e4tt klient tog emot token, vilket m\u00f6jliggjorde token-stuffing-attacker.<\/p>\n\n\n\n

Auktoriseringskodfl\u00f6det med PKCE eliminerar dessa problem i grunden. Token utbyts aldrig i URL:en, utan alltid via en server-till-server POST-beg\u00e4ran fr\u00e5n din backend till auktoriseringsserverns token-endpoint. Den kryptografiska bindningen med code_verifier\/code_challenge s\u00e4kerst\u00e4ller att bara den klient som initierade fl\u00f6det kan slutf\u00f6ra det, oavsett om en angripare lyckas f\u00e5nga upp auktoriseringskoden i transit.<\/p>\n\n\n\n

Hur PKCE-bindningen fungerar matematiskt<\/h3>\n\n\n\n

PKCE bygger p\u00e5 pre-image-resistansen hos SHA-256. Fl\u00f6det fungerar i fem steg. Din app genererar ett slumpm\u00e4ssigt code_verifier<\/code> p\u00e5 43-128 tecken. Den ber\u00e4knar sedan code_challenge = BASE64URL(SHA256(code_verifier))<\/code>. Auktoriseringsservern tar emot code_challenge och lagrar den kopplad till auktoriseringskoden. Vid token-utbytet skickar appen code_verifier i klartext. Servern ber\u00e4knar SHA-256 av code_verifier och j\u00e4mf\u00f6r med den lagrade code_challenge. En angripare som interceptade code_challenge i steg 2 kan inte bak\u00e5tber\u00e4kna code_verifier eftersom SHA-256 \u00e4r en env\u00e4gsfunktion utan praktisk inversm\u00f6jlighet.<\/p>\n\n\n\n

Enligt RFC 9126 rekommenderas PKCE nu f\u00f6r alla OAuth-klienter<\/strong>, inte bara mobil- och SPA-applikationer. Konfidentiella klienter med klienthemlighet b\u00f6r ocks\u00e5 anv\u00e4nda PKCE som ett extra f\u00f6rsvarslager, eftersom det skyddar mot scenarion d\u00e4r auktoriseringsserverns lagring av code_challenge inte angrips direkt men kodinterception sker i n\u00e4tverket.<\/p>\n\n\n\n

F\u00f6ruts\u00e4ttningar<\/h2>\n\n\n\n

Innan du b\u00f6rjar beh\u00f6ver du dessa verktyg och kunskaper p\u00e5 plats:<\/p>\n\n\n\n

Krav<\/th>Version \/ detalj<\/th>Syfte i projektet<\/th><\/tr><\/thead>
Node.js<\/td>22.x LTS (minst 18.x)<\/td>Runtime med inbyggd crypto<\/code>-modul<\/td><\/tr>
npm<\/td>10.x<\/td>Pakethantering och skriptk\u00f6ring<\/td><\/tr>
Express<\/td>4.21.x<\/td>HTTP-server och routing<\/td><\/tr>
express-session<\/td>1.18.x<\/td>Sessionslagring server-side<\/td><\/tr>
axios<\/td>1.7.x<\/td>HTTP-klient f\u00f6r token-endpoint<\/td><\/tr>
dotenv<\/td>16.x<\/td>Milj\u00f6variabelhantering<\/td><\/tr>
OAuth 2.0-leverant\u00f6r<\/td>Google, GitHub, Okta eller Keycloak<\/td>Auktoriseringsserver<\/td><\/tr>
Grundl\u00e4ggande Express-kunskap<\/td>Routing, middleware<\/td>F\u00f6rst\u00e5else av kodbasen<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Du beh\u00f6ver ocks\u00e5 en registrerad applikation hos din valda OAuth-leverant\u00f6r. Vid registreringen s\u00e4tter du en godk\u00e4nd redirect URI, t.ex. http:\/\/localhost:3000\/auth\/callback<\/code> f\u00f6r lokal utveckling. Fr\u00e5n leverant\u00f6ren f\u00e5r du ett Client ID<\/strong> och eventuellt ett Client Secret<\/strong>. Public clients som SPA:er och mobilappar registreras utan client_secret och f\u00f6rlitar sig helt p\u00e5 PKCE f\u00f6r s\u00e4kerheten.<\/p>\n\n\n\n

Kontrollera din Node.js-version innan du b\u00f6rjar:<\/p>\n\n\n\n

node --version\n# F\u00f6rv\u00e4ntad output: v22.x.x (eller v20.x.x som minimum)\n\nnpm --version\n# F\u00f6rv\u00e4ntad output: 10.x.x<\/code><\/pre>\n\n\n\n
Steg 1-3: Projektsetup och installation<\/h2>\n\n\n\n
Skapa projektkatalogen och installera beroendena:<\/p>\n\n\n\n
mkdir oauth2-pkce-demo && cd oauth2-pkce-demo\nnpm init -y\nnpm install express express-session axios dotenv\nnpm install --save-dev nodemon<\/code><\/pre>\n\n\n\n
Skapa filstrukturen som h\u00e5ller projektet v\u00e4lorganiserat:<\/p>\n\n\n\n
oauth2-pkce-demo\/\n\u251c\u2500\u2500 .env                   # Hemliga konfigurationsv\u00e4rden (l\u00e4ggs aldrig i git)\n\u251c\u2500\u2500 .gitignore\n\u251c\u2500\u2500 package.json\n\u2514\u2500\u2500 src\/\n    \u251c\u2500\u2500 server.js          # Express-server och grundkonfiguration\n    \u251c\u2500\u2500 pkce.js            # PKCE-nyckelgenerering\n    \u251c\u2500\u2500 routes\/\n    \u2502   \u251c\u2500\u2500 auth.js        # \/auth\/login, \/auth\/callback, \/auth\/logout\n    \u2502   \u2514\u2500\u2500 protected.js   # Skyddade API-rutter\n    \u2514\u2500\u2500 middleware\/\n        \u2514\u2500\u2500 requireAuth.js # Autentiserings- och token-validering<\/code><\/pre>\n\n\n\n
Skapa .env<\/code>-filen med dina OAuth-uppgifter. Byt ut exempelv\u00e4rdena mot riktiga v\u00e4rden fr\u00e5n din leverant\u00f6r:<\/p>\n\n\n\n
# .env\nSESSION_SECRET=byt-ut-detta-till-ett-langt-slumpmassigt-varde-minst-32-tecken\nCLIENT_ID=din-client-id-har\nCLIENT_SECRET=din-client-secret-har\n\n# Redirect URI m\u00e5ste matcha exakt vad du registrerat hos leverant\u00f6ren\nREDIRECT_URI=http:\/\/localhost:3000\/auth\/callback\n\n# Google OAuth-slutpunkter (byt ut mot din leverant\u00f6rs URL:er)\nAUTHORIZATION_ENDPOINT=https:\/\/accounts.google.com\/o\/oauth2\/v2\/auth\nTOKEN_ENDPOINT=https:\/\/oauth2.googleapis.com\/token\nUSERINFO_ENDPOINT=https:\/\/openidconnect.googleapis.com\/v1\/userinfo\n\n# Scopes: openid aktiverar OIDC-l\u00e4get med id_token\nSCOPES=openid email profile\n\nPORT=3000\nNODE_ENV=development<\/code><\/pre>\n\n\n\n
L\u00e4gg omedelbart till .env<\/code> i .gitignore<\/code>. Det \u00e4r det vanligaste misstaget som leder till att API-nycklar exponeras i git-historiken:<\/p>\n\n\n\n
printf \".env\\nnode_modules\/\\n\" > .gitignore<\/code><\/pre>\n\n\n\n
Uppdatera package.json<\/code> med startskript och typ-f\u00e4lt:<\/p>\n\n\n\n
{\n  \"name\": \"oauth2-pkce-demo\",\n  \"version\": \"1.0.0\",\n  \"scripts\": {\n    \"start\": \"node src\/server.js\",\n    \"dev\": \"nodemon src\/server.js\"\n  },\n  \"dependencies\": {\n    \"axios\": \"^1.7.0\",\n    \"dotenv\": \"^16.0.0\",\n    \"express\": \"^4.21.0\",\n    \"express-session\": \"^1.18.0\"\n  },\n  \"devDependencies\": {\n    \"nodemon\": \"^3.0.0\"\n  }\n}<\/code><\/pre>\n\n\n\n
Steg 4-5: Serverkonfiguration och sessionshantering<\/h2>\n\n\n\n
Skapa src\/server.js<\/code>. Det \u00e4r startpunkten som kopplar ihop Express, sessioner och rutter. Varje sessionskonfigurationsparameter har en direkt s\u00e4kerhetsp\u00e5verkan:<\/p>\n\n\n\n
\/\/ src\/server.js\nrequire('dotenv').config();\nconst express = require('express');\nconst session = require('express-session');\nconst authRoutes = require('.\/routes\/auth');\nconst protectedRoutes = require('.\/routes\/protected');\n\nconst app = express();\nconst PORT = process.env.PORT || 3000;\n\n\/\/ Lita p\u00e5 proxy om du k\u00f6r bakom Nginx eller Cloudflare i produktion\napp.set('trust proxy', 1);\n\n\/\/ Sessionskonfiguration\napp.use(session({\n  secret: process.env.SESSION_SECRET,\n  resave: false,\n  saveUninitialized: false,\n  cookie: {\n    secure: process.env.NODE_ENV === 'production', \/\/ Kr\u00e4v HTTPS i produktion\n    httpOnly: true,   \/\/ F\u00f6rhindrar \u00e5tkomst via JavaScript (skyddar mot XSS)\n    sameSite: 'lax',  \/\/ Till\u00e5ter redirect-cookies men blockerar cross-site POST\n    maxAge: 1000 * 60 * 60 * 24 \/\/ 24 timmar\n  }\n}));\n\n\/\/ Rutter\napp.use('\/auth', authRoutes);\napp.use('\/api', protectedRoutes);\n\n\/\/ Startsida\napp.get('\/', (req, res) => {\n  if (req.session.user) {\n    return res.send(`\n      
Inloggad som ${escapeHtml(req.session.user.email)}<\/h1>\n      Visa profil<\/a> |\n      Logga ut<\/a>\n    `);\n  }\n  res.send('
OAuth 2.0 + PKCE Demo<\/h1>Logga in<\/a>');\n});\n\n\/\/ Enkel HTML-escape f\u00f6r att f\u00f6rhindra XSS i svar\nfunction escapeHtml(str) {\n  return String(str)\n    .replace(\/&\/g, '&')\n    .replace(\/<\/g, '<')\n    .replace(\/>\/g, '>')\n    .replace(\/\"\/g, '"');\n}\n\napp.listen(PORT, () => {\n  console.log(`Server k\u00f6rs p\u00e5 http:\/\/localhost:${PORT}`);\n});<\/code><\/pre>\n\n\n\n
Sessionsinst\u00e4llningen httpOnly: true<\/code> \u00e4r kritisk. Den hindrar JavaScript fr\u00e5n att l\u00e4sa sessionscookien, vilket eliminerar den vanligaste XSS-attackvektorn mot sessionstoken. sameSite: 'lax'<\/code> till\u00e5ter att cookien skickas med navigationsredirects, vilket OAuth-fl\u00f6det kr\u00e4ver, men blockerar cookien vid cross-site POST-f\u00f6rfr\u00e5gningar. L\u00e4gg m\u00e4rke till att vi k\u00f6r med secure: false<\/code> lokalt under utveckling men s\u00e4tter secure: true<\/code> i produktion via milj\u00f6variabeln.<\/p>\n\n\n\n
Observera \u00e4ven escapeHtml<\/code>-funktionen i startsidan. Att skriva ut req.session.user.email<\/code> direkt i HTML utan escape skapar en stored XSS-s\u00e5rbarhet om ett konto registrerats med ett epostnamn som inneh\u00e5ller HTML-tecken. Det \u00e4r ett litet till\u00e4gg med stor s\u00e4kerhetsp\u00e5verkan.<\/p>\n\n\n\n
Steg 6: PKCE-nyckelgenerering<\/h2>\n\n\n\n
Skapa src\/pkce.js<\/code> med den kryptografiska logiken. Node.js inbyggda crypto<\/code>-modul hanterar allt. Inga externa beroenden beh\u00f6vs f\u00f6r den h\u00e4r k\u00e4rndelen:<\/p>\n\n\n\n
\/\/ src\/pkce.js\nconst crypto = require('crypto');\n\n\/\/ Genererar ett kryptografiskt s\u00e4kert code_verifier.\n\/\/ RFC 7636 kr\u00e4ver 43-128 tecken fr\u00e5n alfabetet [A-Z a-z 0-9 - . _ ~].\n\/\/ 32 slumpm\u00e4ssiga bytes base64url-kodade ger exakt 43 tecken utan padding.\nfunction generateCodeVerifier() {\n  return crypto.randomBytes(32).toString('base64url');\n}\n\n\/\/ Ber\u00e4knar code_challenge fr\u00e5n code_verifier med S256-metoden.\n\/\/ S256 = BASE64URL(SHA256(ASCII(code_verifier)))\n\/\/ Auktoriseringsservern lagrar code_challenge och verifierar\n\/\/ att SHA256(verifier) == challenge vid tokenutbytet.\nfunction generateCodeChallenge(codeVerifier) {\n  const hash = crypto.createHash('sha256').update(codeVerifier).digest();\n  return hash.toString('base64url');\n}\n\n\/\/ Genererar ett kryptografiskt slumpm\u00e4ssigt state-v\u00e4rde.\n\/\/ State-parametern skyddar mot CSRF-attacker i OAuth-fl\u00f6det.\nfunction generateState() {\n  return crypto.randomBytes(16).toString('hex');\n}\n\nmodule.exports = { generateCodeVerifier, generateCodeChallenge, generateState };<\/code><\/pre>\n\n\n\n
Varf\u00f6r base64url<\/code> och inte standard base64? Standard base64 anv\u00e4nder tecknen +<\/code>, \/<\/code> och =<\/code> som m\u00e5ste URL-encodas. Base64url ers\u00e4tter dem med -<\/code>, _<\/code> och utel\u00e4mnar padding, vilket ger en str\u00e4ng som \u00e4r direkt s\u00e4ker att inkludera i URL-parametrar utan ytterligare encoding. RFC 7636 specificerar explicit base64url-encoding f\u00f6r b\u00e5de code_verifier och code_challenge.<\/p>\n\n\n\n
Undvik 'plain'<\/code>-metoden f\u00f6r code_challenge. Den skickar code_verifier i klartext som code_challenge, vilket eliminerar PKCE:s skydd helt. En angripare som f\u00e5ngade auktoriseringsf\u00f6rfr\u00e5gan har d\u00e5 allt som beh\u00f6vs f\u00f6r att byta koden mot tokens. RFC 9700 rekommenderar att auktoriseringsservrar avvisar plain<\/code>-metoden och bara accepterar S256<\/code>.<\/p>\n\n\n\n
Steg 7-8: Auktoriseringsfl\u00f6de och redirect<\/h2>\n\n\n\n
Skapa src\/routes\/auth.js<\/code>. Den hanterar tre slutpunkter: \/login<\/code> som startar PKCE-fl\u00f6det, \/callback<\/code> som tar emot auktoriseringskoden fr\u00e5n leverant\u00f6ren, och \/logout<\/code> som avslutar sessionen:<\/p>\n\n\n\n
\/\/ src\/routes\/auth.js\nconst express = require('express');\nconst axios = require('axios');\nconst { generateCodeVerifier, generateCodeChallenge, generateState } = require('..\/pkce');\n\nconst router = express.Router();\n\n\/\/ Steg 7: Starta OAuth 2.0 + PKCE-fl\u00f6det\nrouter.get('\/login', (req, res) => {\n  const codeVerifier = generateCodeVerifier();\n  const codeChallenge = generateCodeChallenge(codeVerifier);\n  const state = generateState();\n\n  \/\/ Spara code_verifier och state i sessionen INNAN redirect.\n  \/\/ code_verifier skickas ALDRIG till auktoriseringsservern.\n  req.session.codeVerifier = codeVerifier;\n  req.session.oauthState = state;\n\n  const params = new URLSearchParams({\n    client_id: process.env.CLIENT_ID,\n    redirect_uri: process.env.REDIRECT_URI,\n    response_type: 'code',\n    scope: process.env.SCOPES,\n    state: state,\n    code_challenge: codeChallenge,\n    code_challenge_method: 'S256'\n  });\n\n  const authUrl = `${process.env.AUTHORIZATION_ENDPOINT}?${params}`;\n  res.redirect(authUrl);\n});\n\n\/\/ Steg 8: Hantera callback fr\u00e5n auktoriseringsservern\nrouter.get('\/callback', async (req, res) => {\n  const { code, state, error, error_description } = req.query;\n\n  \/\/ Kontrollera om auktoriseringsservern returnerade ett fel\n  if (error) {\n    console.error('OAuth-fel:', error, error_description);\n    return res.status(400).send(`Auktoriseringsfel: ${error}`);\n  }\n\n  \/\/ Verifiera state-parametern f\u00f6r att f\u00f6rhindra CSRF-attacker\n  if (!state || state !== req.session.oauthState) {\n    return res.status(403).send('Ogiltig state-parameter. M\u00f6jlig CSRF-attack.');\n  }\n\n  \/\/ H\u00e4mta code_verifier fr\u00e5n sessionen\n  const codeVerifier = req.session.codeVerifier;\n  if (!codeVerifier) {\n    return res.status(400).send('Saknad code_verifier. B\u00f6rja om inloggningsprocessen.');\n  }\n\n  try {\n    \/\/ Byt auktoriseringskoden mot access_token och refresh_token\n    const tokenResponse = await axios.post(\n      process.env.TOKEN_ENDPOINT,\n      new URLSearchParams({\n        grant_type: 'authorization_code',\n        client_id: process.env.CLIENT_ID,\n        client_secret: process.env.CLIENT_SECRET, \/\/ Utel\u00e4mna f\u00f6r public clients\n        code: code,\n        redirect_uri: process.env.REDIRECT_URI,\n        code_verifier: codeVerifier \/\/ PKCE: verifier som auktoriseringsservern kontrollerar\n      }),\n      { headers: { 'Content-Type': 'application\/x-www-form-urlencoded' } }\n    );\n\n    const { access_token, refresh_token, expires_in } = tokenResponse.data;\n\n    \/\/ Rensa PKCE-data fr\u00e5n sessionen direkt efter lyckad utbyte\n    delete req.session.codeVerifier;\n    delete req.session.oauthState;\n\n    \/\/ H\u00e4mta anv\u00e4ndarinformation med access_token\n    const userResponse = await axios.get(process.env.USERINFO_ENDPOINT, {\n      headers: { Authorization: `Bearer ${access_token}` }\n    });\n\n    \/\/ Spara autentiseringsdata i sessionen\n    req.session.user = userResponse.data;\n    req.session.accessToken = access_token;\n    req.session.refreshToken = refresh_token || null;\n    req.session.tokenExpiry = Date.now() + (expires_in * 1000);\n\n    res.redirect('\/');\n  } catch (err) {\n    const errData = err.response?.data;\n    console.error('Token-utbytesfel:', errData || err.message);\n    res.status(500).send('Autentisering misslyckades. F\u00f6rs\u00f6k igen.');\n  }\n});\n\n\/\/ Steg 12: Logga ut och f\u00f6rst\u00f6r sessionen\nrouter.get('\/logout', (req, res) => {\n  req.session.destroy((err) => {\n    if (err) {\n      return res.status(500).send('Utloggning misslyckades.');\n    }\n    res.clearCookie('connect.sid');\n    res.redirect('\/');\n  });\n});\n\nmodule.exports = router;<\/code><\/pre>\n\n\n\n
State-valideringen p\u00e5 raderna 35-38 \u00e4r obligatorisk. Utan den kan en angripare lura din app att acceptera en auktoriseringskod fr\u00e5n en annan anv\u00e4ndares inloggningssession. Det klassiska OAuth CSRF-angreppet fungerar s\u00e5: angriparen initierar ett inloggningsfl\u00f6de, avbryter det och ger offret en l\u00e4nk till callback-URL:en med angriparens kod. Offrets webbl\u00e4sare skickar offrets session-cookie till din callback, och om du inte kontrollerar state loggas offret in som angriparen. Varje nytt inloggningsf\u00f6rs\u00f6k genererar ett nytt, unikt state-v\u00e4rde som bara g\u00e4ller f\u00f6r den specifika sessionen.<\/p>\n\n\n\n
Steg 9: Autentiseringsmiddleware och skyddade rutter<\/h2>\n\n\n\n
Skapa middleware som kontrollerar b\u00e5de autentisering och token-giltighet, med automatisk f\u00f6rnyelse via refresh_token:<\/p>\n\n\n\n
\/\/ src\/middleware\/requireAuth.js\nconst axios = require('axios');\n\nasync function requireAuth(req, res, next) {\n  \/\/ Kontrollera att anv\u00e4ndaren \u00e4r inloggad\n  if (!req.session.user || !req.session.accessToken) {\n    return res.status(401).json({\n      error: 'Inte autentiserad.',\n      loginUrl: '\/auth\/login'\n    });\n  }\n\n  \/\/ F\u00f6rnya token 60 sekunder innan den g\u00e5r ut f\u00f6r att undvika race conditions\n  const bufferMs = 60 * 1000;\n  const tokenExpiresSoon = req.session.tokenExpiry &&\n    Date.now() > req.session.tokenExpiry - bufferMs;\n\n  if (tokenExpiresSoon) {\n    if (!req.session.refreshToken) {\n      req.session.destroy(() => {});\n      return res.status(401).json({\n        error: 'Session utg\u00e5ngen.',\n        loginUrl: '\/auth\/login'\n      });\n    }\n\n    try {\n      const refreshResponse = await axios.post(\n        process.env.TOKEN_ENDPOINT,\n        new URLSearchParams({\n          grant_type: 'refresh_token',\n          client_id: process.env.CLIENT_ID,\n          client_secret: process.env.CLIENT_SECRET,\n          refresh_token: req.session.refreshToken\n        }),\n        { headers: { 'Content-Type': 'application\/x-www-form-urlencoded' } }\n      );\n\n      const { access_token, refresh_token, expires_in } = refreshResponse.data;\n      req.session.accessToken = access_token;\n      \/\/ Vissa leverant\u00f6rer roterar refresh_token; beh\u00e5ll gamla om ny saknas\n      req.session.refreshToken = refresh_token || req.session.refreshToken;\n      req.session.tokenExpiry = Date.now() + (expires_in * 1000);\n    } catch (err) {\n      req.session.destroy(() => {});\n      return res.status(401).json({\n        error: 'Token-f\u00f6rnyelse misslyckades.',\n        loginUrl: '\/auth\/login'\n      });\n    }\n  }\n\n  next();\n}\n\nmodule.exports = requireAuth;<\/code><\/pre>\n\n\n\n
Skapa de skyddade rutterna i src\/routes\/protected.js<\/code>:<\/p>\n\n\n\n
\/\/ src\/routes\/protected.js\nconst express = require('express');\nconst requireAuth = require('..\/middleware\/requireAuth');\n\nconst router = express.Router();\n\n\/\/ Till\u00e4mpa autentiseringsmiddleware p\u00e5 alla \/api-rutter\nrouter.use(requireAuth);\n\nrouter.get('\/profile', (req, res) => {\n  res.json({\n    message: 'Profildata h\u00e4mtad',\n    user: {\n      sub: req.session.user.sub,\n      name: req.session.user.name,\n      email: req.session.user.email\n    },\n    tokenExpiry: new Date(req.session.tokenExpiry).toISOString()\n  });\n});\n\nrouter.get('\/dashboard', (req, res) => {\n  res.json({\n    message: `V\u00e4lkommen tillbaka, ${req.session.user.name || req.session.user.email}`,\n    scopes: process.env.SCOPES.split(' ')\n  });\n});\n\nmodule.exports = router;<\/code><\/pre>\n\n\n\n
Observera att vi returnerar ett minimalt subset av anv\u00e4ndardata fr\u00e5n \/api\/profile<\/code>. Vi undviker att exponera hela req.session.user<\/code>-objektet direkt eftersom det kan inneh\u00e5lla mer information fr\u00e5n leverant\u00f6ren \u00e4n vad frontend-koden beh\u00f6ver. Det minimerar datam\u00e4ngden som exponeras vid eventuell IDOR-s\u00e5rbarhet. L\u00e4s mer om dessa m\u00f6nster i v\u00e5r guide om OWASP Top 10 i Node.js<\/a>.<\/p>\n\n\n\n
Steg 10-11: Testning av hela OAuth-fl\u00f6det<\/h2>\n\n\n\n
Starta servern i utvecklingsl\u00e4ge:<\/p>\n\n\n\n
npm run dev\n\n# F\u00f6rv\u00e4ntad terminal-output:\n# [nodemon] starting `node src\/server.js`\n# Server k\u00f6rs p\u00e5 http:\/\/localhost:3000<\/code><\/pre>\n\n\n\n
\u00d6ppna webbl\u00e4saren och navigera till http:\/\/localhost:3000<\/code>. Klicka p\u00e5 “Logga in”. Du omdirigeras till auktoriseringsservern. Granska URL-parametrarna i adressf\u00e4ltet. Du ska se code_challenge<\/code>, code_challenge_method=S256<\/code> och state<\/code>. Du ser aldrig<\/strong> code_verifier<\/code> i URL:en, den existerar bara i din server-session.<\/p>\n\n\n\n
Efter godk\u00e4nd inloggning omdirigeras du till \/auth\/callback?code=...&state=...<\/code>. Servern verifierar state, h\u00e4mtar code_verifier fr\u00e5n sessionen och byter auktoriseringskoden mot tokens. Du hamnar tillbaka p\u00e5 startsidan inloggad.<\/p>\n\n\n\n
Testa det skyddade API:et med curl. Du beh\u00f6ver en aktiv session-cookie fr\u00e5n webbl\u00e4sarens developer tools, eller spara den under inloggning:<\/p>\n\n\n\n
# Spara session-cookie under inloggning\ncurl -c \/tmp\/oauth-cookies.txt -L http:\/\/localhost:3000\/auth\/login\n\n# Testa skyddad rutt med sparad cookie\ncurl -b \/tmp\/oauth-cookies.txt http:\/\/localhost:3000\/api\/profile\n\n# F\u00f6rv\u00e4ntad JSON-respons:\n{\n  \"message\": \"Profildata h\u00e4mtad\",\n  \"user\": {\n    \"sub\": \"110169484474386276334\",\n    \"name\": \"Anna Lindqvist\",\n    \"email\": \"anna@example.se\"\n  },\n  \"tokenExpiry\": \"2026-06-18T16:30:00.000Z\"\n}\n\n# Test utan cookie: ska returnera 401\ncurl http:\/\/localhost:3000\/api\/profile\n# {\"error\":\"Inte autentiserad.\",\"loginUrl\":\"\/auth\/login\"}<\/code><\/pre>\n\n\n\n
Observera att curl-fl\u00f6det kr\u00e4ver att du manuellt godk\u00e4nner inloggning i webbl\u00e4saren eftersom auktoriseringsservern presenterar sitt eget formul\u00e4r. I automatiserade integrationstester anv\u00e4nds vanligtvis en test-OAuth-server som oidc-provider<\/strong> eller en mock-implementation.<\/p>\n\n\n\n
Komplett projekt\u00f6versikt: hela datafl\u00f6det<\/h2>\n\n\n\n
H\u00e4r \u00e4r en fullst\u00e4ndig bild av hur data fl\u00f6dar genom systemet fr\u00e5n f\u00f6rsta click till aktiv session:<\/p>\n\n\n\n
Steg<\/th>Akt\u00f6r<\/th>\u00c5tg\u00e4rd<\/th>Data som skickas<\/th>Data som sparas<\/th><\/tr><\/thead>
1<\/td>Browser<\/td>GET \/auth\/login<\/td>Session-cookie<\/td>Ingenting<\/td><\/tr>
2<\/td>Node.js-server<\/td>Genererar verifier, challenge och state<\/td>Ingenting externt<\/td>code_verifier, oauthState i session<\/td><\/tr>
3<\/td>Node.js-server<\/td>Redirect till auktoriseringsserver<\/td>client_id, code_challenge, S256, state, scope<\/td>Ingenting nytt<\/td><\/tr>
4<\/td>Anv\u00e4ndare<\/td>Loggar in och godk\u00e4nner<\/td>Inloggningsuppgifter till auktoriseringsservern<\/td>Hos auktoriseringsservern<\/td><\/tr>
5<\/td>Auktoriseringsserver<\/td>Redirect till \/auth\/callback<\/td>code (eng\u00e5ngsbruk), state<\/td>Ingenting p\u00e5 klienten<\/td><\/tr>
6<\/td>Node.js-server<\/td>Verifierar state, h\u00e4mtar code_verifier ur session<\/td>Intern sessionslookup<\/td>Ingenting nytt<\/td><\/tr>
7<\/td>Node.js-server<\/td>POST till token_endpoint<\/td>code, code_verifier, client_id, redirect_uri<\/td>Ingenting \u00e4nnu<\/td><\/tr>
8<\/td>Auktoriseringsserver<\/td>Verifierar SHA256(verifier) == challenge<\/td>Returnerar access_token, refresh_token<\/td>Hos auktoriseringsservern<\/td><\/tr>
9<\/td>Node.js-server<\/td>GET userinfo med access_token<\/td>Bearer-token i header<\/td>user, accessToken, refreshToken, tokenExpiry i session<\/td><\/tr>
10<\/td>Node.js-server<\/td>Rensar PKCE-data, redirect till \/<\/td>Session-cookie till browser<\/td>code_verifier och oauthState raderas<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Vanliga misstag som kostar tid<\/h2>\n\n\n\n
Dessa sex misstag uppst\u00e5r konsekvent i OAuth 2.0 + PKCE-implementationer och leder till antingen s\u00e4kerhetsh\u00e5l eller brutna fl\u00f6den.<\/p>\n\n\n\n
Misstag 1: Skickar code_verifier i auktoriseringsf\u00f6rfr\u00e5gan<\/h3>\n\n\n\n
Det absolut vanligaste misstaget bland utvecklare som l\u00e4ser PKCE f\u00f6r f\u00f6rsta g\u00e5ngen: skicka code_verifier<\/code> ist\u00e4llet f\u00f6r code_challenge<\/code> i steg 3. Auktoriseringsservern tar emot en parameter den inte f\u00f6rst\u00e5r, fl\u00f6det misslyckas med invalid_request<\/code>, och felmeddelandena ger s\u00e4llan tydlig v\u00e4gledning. Regeln \u00e4r enkel: code_challenge<\/code> g\u00e5r till auktoriseringsservern i steg 3. code_verifier<\/code> g\u00e5r till token-endpoint i steg 7. Aldrig tv\u00e4rtom.<\/p>\n\n\n\n
Misstag 2: \u00c5teranv\u00e4nder code_verifier mellan sessioner<\/h3>\n\n\n\n
RFC 7636 kr\u00e4ver att code_verifier \u00e4r ny f\u00f6r varje auktoriseringsf\u00f6rfr\u00e5gan<\/strong>. Om du lagrar code_verifier i en global variabel ist\u00e4llet f\u00f6r i sessionen kan ett race condition uppst\u00e5: tv\u00e5 parallella inloggningar blandar ihop varandras verifiers. Det leder till sporadiska invalid_grant<\/code>-fel som \u00e4r n\u00e4stintill om\u00f6jliga att reproducera i lokal utveckling men dyker upp regelbundet under h\u00f6g trafik i produktion.<\/p>\n\n\n\n
Misstag 3: Hoppar \u00f6ver state-valideringen<\/h3>\n\n\n\n
State-parametern \u00e4r inte valfri. Utan state-validering i callback-hanteraren exponerar du appen f\u00f6r OAuth CSRF-attacker. OWASP dokumenterar detta angreppsm\u00f6nster<\/a> som ett av de vanligaste OAuth-s\u00e4kerhetsproblemen. Resultatet av en lyckad attack \u00e4r att angriparen loggas in som ett offer i din app, eller att offrets konto kopplas till angriparens externa identitet.<\/p>\n\n\n\n
Misstag 4: Lagrar access_token i localStorage<\/h3>\n\n\n\n
M\u00e5nga tutorials visar att man sparar access_token i webbl\u00e4sarens localStorage<\/code> f\u00f6r att sedan skicka den med API-anrop via JavaScript. Det \u00e4r ett allvarligt s\u00e4kerhetsfel. localStorage \u00e4r \u00e5tkomlig fr\u00e5n all JavaScript p\u00e5 sidan, vilket inneb\u00e4r att en enda XSS-s\u00e5rbarhet ger angriparen tillg\u00e5ng till token. Lagra alltid token server-side i en HTTP-only session-cookie, som vi g\u00f6r i den h\u00e4r implementationen. Se v\u00e5r guide om Node.js sessionshantering<\/a> f\u00f6r detaljer om s\u00e4ker cookiekonfiguration.<\/p>\n\n\n\n
Misstag 5: Anv\u00e4nder ‘plain’ som code_challenge_method<\/h3>\n\n\n\n
Plain-metoden skickar code_verifier som code_challenge i klartext. Det inneb\u00e4r att auktoriseringsservern tar emot den faktiska verifieraren redan i steg 3, och en angripare som f\u00e5ngar upp auktoriseringsf\u00f6rfr\u00e5gan har allt som beh\u00f6vs f\u00f6r att byta koden mot tokens. Plain-metoden existerar bara f\u00f6r bak\u00e5tkompatibilitet med \u00e4ldre system. Moderna auktoriseringsservrar ska konfigureras att avvisa plain och bara acceptera S256.<\/p>\n\n\n\n
Misstag 6: Gl\u00f6mmer att rensa PKCE-data efter tokenutbytet<\/h3>\n\n\n\n
code_verifier och oauthState ska raderas ur sessionen direkt efter att tokenutbytet lyckats. Om du beh\u00e5ller dem uppst\u00e5r f\u00f6rvirring om anv\u00e4ndaren startar ett nytt inloggningsfl\u00f6de utan att logga ut, och du riskerar att sessionen inneh\u00e5ller stale PKCE-data fr\u00e5n tidigare fl\u00f6den. I v\u00e5r implementation hanteras detta med delete req.session.codeVerifier<\/code> och delete req.session.oauthState<\/code> direkt efter lyckad token-h\u00e4mtning.<\/p>\n\n\n\n
Fels\u00f6kningsguide: 8 vanliga OAuth-fel<\/h2>\n\n\n\n
Dessa \u00e5tta fel dyker upp regelbundet i PKCE-implementationer. H\u00e4r \u00e4r symptomen, orsakerna och l\u00f6sningarna:<\/p>\n\n\n\n
Felmeddelande<\/th>HTTP-kod<\/th>Vanligaste orsak<\/th>L\u00f6sning<\/th><\/tr><\/thead>
invalid_grant<\/code><\/td>400<\/td>code_verifier matchar inte challenge, eller koden har redan anv\u00e4nts<\/td>Verifiera att SHA256(verifier) ger r\u00e4tt challenge. Auktoriseringskoder \u00e4r eng\u00e5ngsbruk.<\/td><\/tr>
invalid_request<\/code><\/td>400<\/td>Redirect URI ej registrerad, eller saknad PKCE-parameter<\/td>Kontrollera att redirect_uri matchar exakt vad du registrerat hos leverant\u00f6ren, tecken f\u00f6r tecken.<\/td><\/tr>
invalid_client<\/code><\/td>401<\/td>Fel client_id eller client_secret<\/td>Kontrollera .env-v\u00e4rdena. Koda aldrig in dem direkt i k\u00e4llkoden.<\/td><\/tr>
State mismatch (din 403)<\/td>403<\/td>Sessionen gick ut mellan login och callback, eller cookies blockeras<\/td>Kontrollera att sameSite=’lax’ \u00e4r satt och att sessionen lever l\u00e4nge nog f\u00f6r inloggningsfl\u00f6det.<\/td><\/tr>
CORS-fel vid token-endpoint<\/td>Webbl\u00e4sarfel<\/td>Token-request g\u00f6rs direkt fr\u00e5n frontend-JavaScript<\/td>Token-request M\u00c5STE g\u00f6ras server-side. Flytta axios.post-anropet till Node.js-backend.<\/td><\/tr>
access_denied<\/code><\/td>400<\/td>Anv\u00e4ndaren nekade \u00e5tkomst, eller scope saknas i leverant\u00f6rens konfiguration<\/td>Kontrollera att beg\u00e4rda scopes \u00e4r aktiverade i leverant\u00f6rens app-konfiguration.<\/td><\/tr>
Cannot read properties of undefined (codeVerifier)<\/td>500<\/td>Session initialiserades inte, eller express-session saknas<\/td>Verifiera att app.use(session(…)) k\u00f6rs INNAN routing-middleware i server.js.<\/td><\/tr>
redirect_uri_mismatch<\/code><\/td>400<\/td>URI i koden matchar inte registrerad URI hos leverant\u00f6ren<\/td>URI:n m\u00e5ste matcha tecken f\u00f6r tecken inklusive avslutande snedstreck och PORT-nummer.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
F\u00f6r djupare fels\u00f6kning, aktivera tempor\u00e4r logging av OAuth-parametrarna. Logga aldrig code_verifier, access_token eller refresh_token i produktionsloggar:<\/p>\n\n\n\n
\/\/ Fels\u00f6kningslogging: aktivera bara i development\nif (process.env.NODE_ENV === 'development') {\n  console.log('OAuth-parametrar:', {\n    authorization_endpoint: process.env.AUTHORIZATION_ENDPOINT,\n    client_id: process.env.CLIENT_ID,\n    redirect_uri: process.env.REDIRECT_URI,\n    scope: process.env.SCOPES,\n    code_challenge_method: 'S256',\n    \/\/ Logga ALDRIG code_verifier, access_token eller refresh_token\n    code_challenge_preview: codeChallenge.substring(0, 10) + '...'\n  });\n}<\/code><\/pre>\n\n\n\n
Avancerade tekniker och produktionsinst\u00e4llningar<\/h2>\n\n\n\n
Grundimplementationen fungerar f\u00f6r prototyping och inl\u00e4rning. Produktionsmilj\u00f6er kr\u00e4ver ytterligare h\u00e4rdning p\u00e5 fyra niv\u00e5er:<\/p>\n\n\n\n
Persistent sessionslagring med Redis<\/h3>\n\n\n\n
Minnesbaserad sessionslagring f\u00f6rsvinner vid serveromstart. F\u00f6r produktionsmilj\u00f6er med flera instanser kr\u00e4vs en delad sessionslagring som Redis. Installera connect-redis<\/strong>:<\/p>\n\n\n\n
npm install connect-redis redis\n\n\/\/ src\/server.js - produktionskonfiguration\nconst RedisStore = require('connect-redis').default;\nconst { createClient } = require('redis');\n\nconst redisClient = createClient({ url: process.env.REDIS_URL });\nredisClient.connect().catch(console.error);\n\napp.use(session({\n  store: new RedisStore({ client: redisClient }),\n  secret: process.env.SESSION_SECRET,\n  resave: false,\n  saveUninitialized: false,\n  cookie: {\n    secure: true,          \/\/ Kr\u00e4v HTTPS i produktion\n    httpOnly: true,\n    sameSite: 'lax',\n    maxAge: 1000 * 60 * 60 * 8 \/\/ 8 timmar\n  }\n}));<\/code><\/pre>\n\n\n\n
OpenID Connect ID-token-validering<\/h3>\n\n\n\n
Om auktoriseringsservern returnerar ett id_token<\/code> (ett JWT med anv\u00e4ndarinformation via OpenID Connect), validera det innan du litar p\u00e5 inneh\u00e5llet. Biblioteket jose<\/strong> hanterar JWKS-baserad JWT-validering:<\/p>\n\n\n\n
npm install jose\n\nconst { createRemoteJWKSet, jwtVerify } = require('jose');\n\nconst JWKS = createRemoteJWKSet(\n  new URL('https:\/\/accounts.google.com\/.well-known\/openid-configuration')\n);\n\nasync function validateIdToken(id_token) {\n  const { payload } = await jwtVerify(id_token, JWKS, {\n    issuer: 'https:\/\/accounts.google.com',\n    audience: process.env.CLIENT_ID\n  });\n  \/\/ Kontrollera nonce om du anv\u00e4nde en i auktoriseringsf\u00f6rfr\u00e5gan\n  return payload;\n}<\/code><\/pre>\n\n\n\n
L\u00e4s mer om JWT-validering i v\u00e5r guide om JWT-autentisering i Node.js<\/a>.<\/p>\n\n\n\n
PKCE-fl\u00f6det utan client_secret f\u00f6r public clients<\/h3>\n\n\n\n
Single-page applikationer och mobilappar kan inte s\u00e4kra ett client_secret; k\u00e4llkoden \u00e4r alltid tillg\u00e4nglig f\u00f6r anv\u00e4ndaren. F\u00f6r dessa public clients utel\u00e4mnas client_secret helt fr\u00e5n token-f\u00f6rfr\u00e5gan. PKCE ers\u00e4tter behovet av client_secret eftersom code_verifier bevisar att r\u00e4tt klient, den som skapade code_challenge, slutf\u00f6rde fl\u00f6det. Registrera appen som “public client” hos leverant\u00f6ren f\u00f6r att till\u00e5ta tokenutbyte utan secret.<\/p>\n\n\n\n
Hastighetsbegr\u00e4nsning p\u00e5 auth-endpoints<\/h3>\n\n\n\n
OAuth-endpoints \u00e4r frekventa m\u00e5l f\u00f6r scanning och missbruk. L\u00e4gg till rate limiting p\u00e5 \/auth\/login<\/code> och \/auth\/callback<\/code>. V\u00e5r guide om rate limiting i Node.js<\/a> visar hur du konfigurerar express-rate-limit f\u00f6r just auth-fl\u00f6den. Kombinera med tv\u00e5faktorsautentisering i Node.js<\/a> f\u00f6r ett komplett autentiseringslager. Se \u00e4ven Express.js officiella s\u00e4kerhetsguide<\/a> f\u00f6r ytterligare produktionsh\u00e4rdning med Helmet.js och Content Security Policy. CSRF-skydd i Node.js<\/a> t\u00e4cker de attacker som OAuth-fl\u00f6dets state-parameter f\u00f6rhindrar i autentiseringsfl\u00f6det, men som kan dyka upp i andra delar av din app. Auth0:s dokumentation om auktoriseringskodfl\u00f6det med PKCE<\/a> ger en leverant\u00f6rsneutral referensimplementation.<\/p>\n\n\n\n
Relaterad l\u00e4sning<\/h2>\n\n\n\n
Relaterade artiklar<\/h3>\n\n\n\n