HMAC vs RSA-signaturer: 150x Raskere [2026]

Skal du signere en JWT, verifisere en webhook fra Stripe, eller bygge autentisering mellom mikrotjenester? Da havner du før eller siden i det samme valget: HMAC (symmetrisk meldingsautentisering) eller en digital signatur som RSA eller ECDSA (asymmetrisk). Valget avgjør hvor raskt systemet ditt signerer og verifiserer, hvor godt hemmeligheter er beskyttet, og hvor enkelt du kan skalere til flere tjenester og partnere uten å dele nøkler du egentlig ikke vil dele.

Denne artikkelen går igjennom HMAC vs RSA-signaturer (og ES256/ECDSA der det er relevant) med ferske tall fra OpenSSL-benchmarks, Auth0s egne ytelsestester og prislister fra AWS, Azure og Google Cloud i 2026. Du får en full sammenligning, en migreringsguide fra HS256 til RS256/ES256, og en tydelig konklusjon basert på faktiske tall, ikke synsing.

Hva er HMAC og hvordan skiller det seg fra digitale signaturer?

HMAC (Hash-based Message Authentication Code) er en symmetrisk mekanisme definert av NIST i FIPS 198-1, publisert i juli 2008. HMAC bruker én delt hemmelig nøkkel som både avsender og mottaker kjenner. Formelen er enkel i bunn: hashfunksjonen (typisk SHA-256) kjøres to ganger over meldingen, kombinert med nøkkelen via XOR-operasjoner (ipad og opad). Resultatet er en kode som beviser at meldingen ikke er endret, og at avsenderen kjenner nøkkelen. Men det beviser ikke hvem avsenderen er blant dem som har nøkkelen, siden alle med samme nøkkel kan generere identiske koder.

Digitale signaturer som RSA og ECDSA er asymmetriske. De bruker et nøkkelpar: en privat nøkkel som kun signereren har, og en offentlig nøkkel som alle mottakere kan bruke til å verifisere. Standarden er FIPS 186-5 (Digital Signature Standard), publisert av NIST 3. februar 2023, og den godkjenner tre metoder: RSA, ECDSA og EdDSA. Den eldre DSA-algoritmen beholdes kun for å verifisere gamle signaturer, ikke for å lage nye.

Forskjellen har direkte konsekvens for arkitektur. Med HMAC må alle parter som skal verifisere en melding også kjenne hemmeligheten. Det betyr at hemmeligheten må deles med hver eneste tjeneste, partner eller mikrotjeneste som trenger å sjekke signaturen. Med RSA eller ECDSA trenger bare utstederen den private nøkkelen. Alle andre kan hente den offentlige nøkkelen, for eksempel via et JWKS-endepunkt, og verifisere uten noen gang å kunne forfalske en ny token selv.

I JWT-verdenen ser du dette som algoritme-identifikatorer i tokenets header: HS256 (HMAC med SHA-256), RS256 (RSASSA-PKCS1 v1.5 med SHA-256, vanligvis 2048-bit RSA-nøkler) og ES256 (ECDSA over NIST P-256-kurven med SHA-256). Alle tre er i praksis bygget på NIST-standardene nevnt over.

HMAC vs RSA vs ECDSA: spesifikasjonstabell

Under følger en oversikt over de tekniske egenskapene til de tre vanligste valgene for meldingsautentisering og signering i moderne systemer.

Egenskap	HMAC-SHA256 (HS256)	RSA-2048 (RS256)	ECDSA P-256 (ES256)
Type	Symmetrisk MAC	Asymmetrisk signatur	Asymmetrisk signatur
Nøkkelstruktur	Én delt hemmelig nøkkel	Privat/offentlig nøkkelpar	Privat/offentlig nøkkelpar
Nøkkelstørrelse	256 bit (anbefalt)	2048 bit (opp til 4096)	256 bit
Tilsvarende sikkerhetsnivå	~128 bit	~112 bit (2048-bit)	~128 bit (tilsvarer RSA-3072)
Signaturstørrelse	32 byte	256 byte	64-72 byte
Standard	FIPS 198-1 / SP 800-224	FIPS 186-5	FIPS 186-5
Krever delt hemmelighet hos alle parter	Ja	Nei	Nei
Egnet for offentlige API-er	Nei (krever nøkkeldeling)	Ja	Ja
Signeringshastighet	Svært høy	Lav	Høy
Verifiseringshastighet	Svært høy	Middels-høy	Middels
Nøkkelrotasjon på tvers av tjenester	Vanskelig (må distribueres på nytt hos alle)	Enkel (kun offentlig nøkkel deles på nytt)	Enkel
Typisk bruksområde	Webhooks, interne systemer	Offentlige JWT-er, IdP-tokens	Mobilklienter, moderne IdP-er

Ytelsesbenchmarks: hvor mye raskere er HMAC egentlig?

Dette er stedet der tallene virkelig skiller seg. Vi har samlet resultater fra tre uavhengige kilder for å unngå at én enkelt benchmark gir et skjevt bilde.

OpenSSL speed-benchmark (RSA-2048 vs ECDSA P-256): På vanlig serverhardware måler OpenSSLs innebygde benchmark-verktøy RSA-2048-signering til rundt 926 signeringer i sekundet og verifisering til rundt 29 368 verifiseringer i sekundet. ECDSA P-256 signerer langt raskere, med rundt 23 100 signeringer i sekundet (omtrent 25x raskere enn RSA-2048), men verifiserer saktere enn RSA, med rundt 8 780 verifiseringer i sekundet. En annen uavhengig OpenSSL-kjøring viser samme mønster: RSA signerer sakte og verifiserer raskt, mens ECDSA signerer raskt og verifiserer relativt sakte.

HMAC-SHA256 i rå tall: Samme type OpenSSL 3.0-benchmark viser at HMAC-SHA256 klarer over 2,7 millioner operasjoner i sekundet på 16-byte blokker, og rundt 2 millioner operasjoner i sekundet på 64-byte blokker. Det er tre til fire størrelsesordener raskere enn RSA-signering på tilsvarende maskinvare, altså tusenvis av ganger raskere, ikke bare noen få prosent.

Auth0s node-jsonwebtoken-bibliotek (ekte JWT-signering): Auth0s egne benchmarks av node-jsonwebtoken-biblioteket viser HS256-koding på 120 423 operasjoner i sekundet i en eldre versjon, mot bare 793 operasjoner i sekundet for RS256 og 2 418 operasjoner i sekundet for ES256. Det gir HS256 en fordel på 50 til over 150 ganger sammenlignet med RS256 i praktisk JWT-koding, avhengig av bibliotekversjon. En tredje uavhengig test bekrefter mønsteret: RS256-verifisering endte på rundt 12 300 operasjoner i sekundet, RS256-signering på rundt 1 006 i sekundet, og HS256 på rundt 91 464 i sekundet, en faktor på cirka 7,5x i favør HMAC selv når man bare ser på verifisering.

Kilde	HS256 (signering)	RS256 (signering)	ES256 (signering)
OpenSSL speed (rå HMAC/RSA/ECDSA)	~2 mill. ops/s	~926 ops/s	~23 100 ops/s
Auth0 node-jsonwebtoken v8.5.1	120 423 ops/s	793 ops/s	2 418 ops/s
Auth0 node-jsonwebtoken v9.0.2	2 264 ops/s	759 ops/s	2 131 ops/s
Uavhengig JWT-benchmark (verifisering)	91 464 ops/s	12 303 ops/s verify / 1 006 ops/s sign	Ikke oppgitt

Konklusjonen fra alle tre kildene er samstemt: HMAC er dramatisk raskere enn RSA på signering, uansett hvilket verktøy eller bibliotek som måles. ECDSA ligger et sted mellom de to, med rask signering men tregere verifisering enn RSA. WorkOS oppsummerer i sin egen sammenligning at RSA-2048-signering typisk er 10 til 50 ganger tregere enn HS256, med HMAC-signering på titalls mikrosekunder mot RSA på enkeltsifrede millisekunder.

Sikkerhet: alg=none, nøkkelforvirring og delte hemmeligheter

Rå hastighet er ikke hele bildet. HMAC og RSA har ulike sikkerhetssvakheter avhengig av hvordan de implementeres.

Algoritme-forvirring og alg=none

JWT-standarden (RFC 7519, JWS) tillater teknisk sett alg: "none", som betyr en usignert token uten integritetsbeskyttelse. OWASPs Web Security Testing Guide beskriver hvordan biblioteker som aksepterer denne verdien uten videre, lar en angriper endre header til {"alg": "none"}, fjerne signaturen, og likevel få tokenet godkjent. Dette er ikke bare et historisk problem: CVE-2026-27804 i Parse Server, CVE-2026-28802 i Authlib, og CVE-2026-39413 i LightRAG viser at samme sårbarhetsklasse dukker opp i nye biblioteker år etter år.

En beslektet og mer snikende variant er nøkkelforvirring: en server forventer RS256, men verifiseringskoden stoler blindt på algoritmen som står i tokenets header. En angriper kan da sette alg: "HS256" og bruke serverens offentlige RSA-nøkkel (som ofte er offentlig tilgjengelig) som HMAC-hemmelighet, og dermed forfalske gyldige tokens. Løsningen er alltid å håndheve en eksplisitt algoritme-allowlist på verifiseringssiden, aldri la tokenets egen header bestemme hvilken algoritme som brukes til å validere den.

Delte hemmeligheter skalerer dårlig

HMAC krever at alle parter som skal verifisere en melding, kjenner den samme hemmeligheten. I et system med én utsteder og én forbruker er dette helt greit. Men i en arkitektur med mange mikrotjenester, tredjepartsintegrasjon eller flere selskaper som skal stole på samme token, betyr det at hemmeligheten må distribueres til alle. Enhver av dem kan da både forfalske tokens og verifisere dem, noe som gjør det umulig å avgjøre hvem som faktisk signerte en gitt melding. Dette er hovedgrunnen til at identity-leverandører som bruker JWKS-baserte offentlige nøkler (RS256/ES256) foretrekkes for API-er som flere uavhengige parter skal verifisere mot.

I praksis ser vi denne avveiningen tydeligst i selskaper som vokser fra én enkelt backend til en distribuert arkitektur. Et team som starter med HMAC fordi det er raskt å implementere, oppdager gjerne først at det blir et problem når en tredje eller fjerde intern tjeneste trenger å verifisere de samme tokenene. På det tidspunktet må hemmeligheten enten distribueres til enda en tjeneste (som øker angrepsflaten for hvert nytt sted den lagres), eller sendes via en sentral hemmelighetstjeneste som alle må ha nettverkstilgang til. Begge løsningene fungerer, men ingen av dem skalerer like elegant som å bare publisere en offentlig nøkkel som enhver tjeneste kan hente fritt uten å noen gang kunne signere noe selv.

Reelle bruksområder: hvem bruker hva?

Valget mellom HMAC og digitale signaturer er ikke teoretisk. Se på hvordan de faktiske markedslederne har løst det:

Stripe signerer alle webhook-utsendelser med HMAC-SHA256. Signaturen sendes i Stripe-Signature-headeren og beregnes som HMAC-SHA256 av en kombinasjon av tidsstempel og rå forespørselsbody, med standard toleranse på 300 sekunder mot replay-angrep.
GitHub bruker samme mønster for sine webhooks: headeren X-Hub-Signature-256 inneholder en HMAC-SHA256 av payloaden, beregnet med en delt hemmelighet utvikleren setter opp i repo-innstillingene.
Auth0 og andre identity-leverandører anbefaler RS256 som standard for ID-tokens og access-tokens nettopp fordi offentlige nøkler kan distribueres via JWKS-endepunkter uten å dele en hemmelighet med hver forbrukende tjeneste.
Interne mikrotjeneste-arkitekturer bruker ofte HMAC for tjeneste-til-tjeneste-autentisering innenfor én stolt sikkerhetssone, hvor hastighetsfordelen veier tyngre enn behovet for nøkkelisolasjon.
Strike, en betalingsplattform, signerer webhook-payloads med HMAC-SHA256 i en X-Webhook-Signature-header, beregnet med en hemmelighet knyttet til det aktuelle abonnementet.

Mønsteret er tydelig: webhooks mellom to kjente parter bruker nesten alltid HMAC, fordi begge parter allerede har en etablert, privat relasjon der en delt hemmelighet er naturlig. JWT-er for offentlige API-er og identitetsplattformer bruker nesten alltid RS256 eller ES256, fordi tokenet skal kunne verifiseres av mange uavhengige tjenester som aldri bør ha makt til å utstede nye tokens selv.

Priser: hva koster HMAC og RSA-signering i skyen?

Hvis du bruker en administrert nøkkeltjeneste (KMS) i stedet for å håndtere nøkler i egen applikasjonskode, varierer kostnaden mellom leverandørene. Her er 2026-prisene fra AWS, Google Cloud og Azure.

Leverandør	Nøkkelkostnad per måned	Kostnad per 10 000 operasjoner	Merknad
AWS KMS	$1,00 per nøkkel (symmetrisk, asymmetrisk og HMAC likt)	$0,15 (asymmetriske operasjoner: sign/verify/encrypt/decrypt)	Ingen prisforskjell mellom HMAC- og RSA-nøkler
Google Cloud KMS	~$0,06 (programvarebeskyttet AES/HMAC), ~$0,99 (HSM)	$0,03 (standard nøkkelbruk)	HSM-beskyttelse koster vesentlig mer enn programvare
Azure Key Vault (RSA-2048, standard)	$1,00 per nøkkel	$0,03	Billigste RSA-tier hos Azure
Azure Key Vault (RSA-3072/4096, ECC, avansert)	$5,00 per nøkkel (første 250 nøkler)	$0,15	Azure priser ikke HMAC-nøkler separat fra RSA-standard

Ingen av de tre store skyleverandørene priser HMAC-operasjoner vesentlig billigere enn RSA-operasjoner direkte i sine offentlige prislister. AWS KMS bruker samme $1/måned per nøkkel uansett type, og fakturerer asymmetriske operasjoner til $0,15 per 10 000 kall. Den reelle kostnadsforskjellen ligger ikke i kronebeløpet per kall, men i hvor mange kall du trenger. Siden RSA-signering er 10-150 ganger tregere enn HMAC i applikasjonskode, betyr det i praksis at høyvolum-systemer som signerer hver eneste token via en ekstern KMS, får en helt annen kostnads- og lastprofil med RSA enn med HMAC, selv om prisen per kall er lik.

De fleste høyvolum-systemer unngår derfor å kalle KMS for hver eneste signering. HMAC-hemmeligheter holdes ofte direkte i applikasjonens minne etter henting fra en hemmelighetstjeneste, mens RSA/ECDSA-nøkler for JWT-utstedelse typisk lagres i en HSM eller KMS kun for selve nøkkelgenereringen, med signeringsoperasjonen selv utført lokalt i tjenesten for å unngå nettverkslatens per token.

Fordeler og ulemper: HMAC vs digitale signaturer

HMAC (HS256)

Fordel: Ekstremt rask, både signering og verifisering, ofte millioner av operasjoner per sekund.
Fordel: Enkel å implementere, krever ingen nøkkelpar-administrasjon eller sertifikathåndtering.
Fordel: Kort signatur (32 byte), som gir mindre tokens og lavere overhead per melding.
Ulempe: Krever at hemmeligheten deles med alle som skal verifisere, noe som gjør det uegnet for offentlige API-er med mange forbrukere.
Ulempe: Kan ikke bevise hvem som signerte blant flere parter som deler nøkkelen (ingen ikke-benekting).
Ulempe: Nøkkelrotasjon krever at alle parter oppdateres samtidig, noe som er operasjonelt krevende ved mange forbrukere.

RSA / ECDSA (RS256 / ES256)

Fordel: Kun utstederen trenger den private nøkkelen. Kompromittering av en verifiserende tjeneste avslører ikke signeringsevnen.
Fordel: Offentlige nøkler kan distribueres fritt via JWKS, ideelt for mikrotjenester og tredjepartsintegrasjon.
Fordel: Gir ikke-benekting: en gyldig signatur beviser hvem som faktisk signerte.
Ulempe: Betydelig tregere enn HMAC, spesielt RSA-signering (opptil 150x tregere i enkelte benchmarks).
Ulempe: Større signaturer (RSA-2048 gir 256-byte signaturer mot HMACs 32 byte), som øker tokenstørrelsen.
Ulempe: Krever nøkkelparadministrasjon, sertifikatrotasjon og ofte en KMS eller HSM for sikker nøkkellagring.

Bibliotekstøtte for HS256, RS256 og ES256 på tvers av språk

Et argument som ofte avgjør valget i praksis, er hvor godt de ulike algoritmene støttes i verktøykassen du allerede bruker. Alle de store JWT-bibliotekene støtter i dag alle tre algoritmene, men modenheten og standardvalget varierer.

Språk/plattform	Vanligste bibliotek	HS256	RS256	ES256
Node.js	jsonwebtoken, jose	Ja	Ja	Ja
Python	PyJWT, python-jose	Ja	Ja	Ja
Java / Kotlin	java-jwt (Auth0), Nimbus JOSE+JWT	Ja	Ja	Ja
Go	golang-jwt/jwt	Ja	Ja	Ja
.NET	System.IdentityModel.Tokens.Jwt	Ja	Ja	Ja
Ruby	ruby-jwt	Ja	Ja	Ja
PHP	firebase/php-jwt	Ja	Ja	Delvis (nyere versjoner)

Forskjellen ligger sjelden i om algoritmen støttes, men i hvor lett det er å gjøre feil. Eldre versjoner av flere av disse bibliotekene, inkludert tidlige utgaver av PyJWT og node-jsonwebtoken, tillot at klienten kunne oppgi alg uten at serveren tvang frem en allowlist, noe som direkte muliggjorde nøkkelforvirrings-angrepet beskrevet over. Nyere versjoner krever eksplisitt at utvikleren spesifiserer hvilke algoritmer som er tillatt ved verifisering, nettopp som svar på denne sårbarhetsklassen. Sjekk alltid changelog og sikkerhetsrådgivninger for biblioteket du bruker før du setter det i produksjon, spesielt hvis prosjektet har ligget uendret i flere år.

Vanlige implementeringsfeil med HMAC og RSA-signaturer

De fleste sikkerhetshendelser knyttet til HMAC og digitale signaturer skyldes ikke svakheter i selve kryptografien, men feil i hvordan den brukes. Her er de vanligste fallgruvene vi ser gjentatt på tvers av kodebaser.

Å stole på tokenets egen alg-header. Dette er den klart vanligste feilen, og den som muliggjør både alg=none-angrepet og nøkkelforvirring. Server-koden skal alltid definere hvilken algoritme som forventes, aldri lese det fra tokenet som skal verifiseres.
Sammenligne HMAC-signaturer med vanlig strenglikhet. Operatorer som == eller === avslutter sammenligningen så snart de finner en avvikende byte, noe som lekker informasjon om hvor mange byte som var riktige gjennom responstid. Bruk alltid en konstant-tid-sammenligning som crypto.timingSafeEqual i Node.js eller hmac.compare_digest i Python.
For korte eller forutsigbare HMAC-hemmeligheter. En HMAC er bare så sterk som hemmeligheten den bruker. En kort hemmelighet, eller en hemmelighet generert fra et forutsigbart mønster, gjør signaturen sårbar for brute-force selv om selve SHA-256-algoritmen er intakt. Bruk minst 256 bit tilfeldig genererte data.
Å gjenbruke samme HMAC-hemmelighet på tvers av miljøer. Samme nøkkel i test, staging og produksjon betyr at et brudd i ett miljø kompromitterer alle. Hvert miljø bør ha sin egen, uavhengig genererte hemmelighet.
Manglende utløpstid og replay-beskyttelse. Både HMAC-signerte webhooks og RSA/ECDSA-signerte JWT-er kan gjenbrukes av en angriper som fanger opp en gyldig forespørsel, med mindre du inkluderer et tidsstempel og håndhever et kort toleransevindu, slik Stripes 300-sekunders grense gjør.
Å bruke RSA-nøkler under 2048 bit. 1024-bit RSA regnes ikke lenger som sikkert av NIST, men eldre systemer og biblioteker med gamle standardverdier finnes fortsatt i drift. Verifiser alltid nøkkellengden ved oppsett av nye tjenester.

Hvordan store identitetsplattformer håndterer nøkkelrotasjon

En praktisk fordel med RS256/ES256 som sjelden nevnes i innledende sammenligninger, er hvor mye enklere nøkkelrotasjon blir. Med HMAC må en ny hemmelighet distribueres til absolutt alle parter samtidig, noe som i praksis tvinger frem enten nedetid eller en komplisert dobbel-nøkkel-periode der begge hemmeligheter godtas midlertidig.

Identitetsplattformer som bruker RS256 eller ES256 løser dette ved å publisere flere gyldige offentlige nøkler samtidig i JWKS-endepunktet, hver merket med en unik kid (key ID) i tokenets header. Når en ny privat nøkkel tas i bruk for signering, legges den tilhørende offentlige nøkkelen til i JWKS-listen før den gamle fjernes. Verifiserende tjenester som allerede cacher JWKS-responsen, henter automatisk den nye nøkkelen basert på kid-verdien i hver innkommende token, uten at noen manuell koordinering kreves. Den gamle nøkkelen kan beholdes i JWKS en periode etter rotasjon, slik at tokens signert med den fortsatt kan verifiseres til de utløper naturlig.

Dette mønsteret, ofte kalt “key rollover”, er en av de sterkeste praktiske grunnene til at større organisasjoner med mange forbrukende tjenester nesten alltid lander på asymmetrisk signering for JWT-baserte systemer, selv når ytelsesforskjellen mot HMAC er betydelig. Kostnaden ved tregere signering blir mindre viktig enn evnen til å rotere nøkler uten koordinert nedetid på tvers av dusinvis eller hundrevis av forbrukende systemer.

5 bruksområder og konkrete anbefalinger

1. Webhook-verifisering mellom to kjente parter. Bruk HMAC-SHA256. Dette er akkurat det Stripe og GitHub gjør, og det finnes ingen god grunn til å bytte til asymmetrisk signering når det bare er to parter med en etablert, privat relasjon.

2. Autentisering mellom mikrotjenester i samme sikkerhetssone. HMAC er som regel riktig valg internt, spesielt når hastighet betyr noe og alle tjenester allerede stoler på hverandre gjennom samme nettverkssegment eller service mesh.

3. Offentlige API-er med tredjepartsutviklere. Bruk RS256 eller ES256. Når eksterne utviklere skal verifisere tokens, må du kunne dele en offentlig nøkkel uten å risikere at noen kan utstede egne gyldige tokens.

4. Single sign-on og identitetsplattformer. RS256 eller ES256 er standard hos de fleste identity-leverandører, nettopp fordi tokens skal verifiseres av mange uavhengige applikasjoner via JWKS uten at noen av dem kan forfalske nye.

5. Mobilapplikasjoner og enheter med begrenset regnekraft. ES256 (ECDSA) er ofte et bedre kompromiss enn RS256 her, siden signaturene er mindre og signeringsoperasjonen er raskere enn RSA, samtidig som du beholder fordelene med asymmetrisk kryptografi.

Migreringsguide: fra HS256 til RS256/ES256

Mange team starter med HS256 fordi det er raskt å sette opp, og oppdager senere at de trenger asymmetrisk signering når systemet vokser til flere tjenester eller eksterne partnere. Slik gjøres overgangen trygt, uten nedetid.

Håndhev en algoritme-allowlist først. Før du endrer noe annet, sørg for at verifiseringskoden din eksplisitt krever algorithms: ["HS256"] og aldri lar tokenets egen header bestemme hvilken algoritme som brukes til validering. Dette stopper nøkkelforvirrings-angrep uansett hva du gjør videre.
Generer et RSA- eller ECDSA-nøkkelpar. Bruk en KMS eller HSM til å generere og lagre den private nøkkelen sikkert. RSA-2048 er minimum for RS256; ES256 med P-256-kurven gir tilsvarende sikkerhet med mindre signaturer.
Publiser den offentlige nøkkelen via et JWKS-endepunkt. Dette er standardformatet identity-leverandører bruker, og lar forbrukende tjenester hente og cache nøkkelen automatisk.
Start med å signere nye tokens med RS256/ES256, men behold HS256-verifisering i en overgangsperiode. Konfigurer verifiseringssiden til å akseptere begge algoritmene i overgangsvinduet, pinnet per utsteder, aldri dynamisk basert på header alene.
Oppdater alle klienter til å hente og cache JWKS-nøkler. Test at samtlige forbrukende tjenester kan verifisere de nye tokens før du går videre.
Overvåk ytelsen. Siden RS256 kan være opptil 150 ganger tregere enn HS256 i signering, mål faktisk gjennomstrømming i produksjon. Vurder om signeringsoperasjonen bør skje lokalt i applikasjonen (raskere) eller via KMS (mer sikkert, men med nettverkslatens).
Fjern HS256 fra allowlisten når migreringen er fullført. Ikke behold gamle algoritmer “for sikkerhets skyld” lenger enn nødvendig. Hver ekstra tillatt algoritme er en ekstra angrepsflate.

Underveis bør du også vurdere token-levetid. Siden RS256/ES256-verifisering koster mer regnekraft enn HMAC, kompenserer mange team med lengre levetid på access-tokens kombinert med gode tilbakekallingsmekanismer, i stedet for å signere på nytt like ofte som de gjorde med HS256.

Kodeeksempel: verifisering med algoritme-allowlist

Uansett om du bruker HMAC eller RSA, er det viktigste sikkerhetstiltaket å aldri stole på algoritmen som står i tokenets egen header. Slik ser en trygg verifisering ut i Node.js med jsonwebtoken-biblioteket:

const jwt = require("jsonwebtoken");

// RIKTIG: algoritmen er hardkodet av utvikleren, ikke lest fra token
function verifyToken(token, publicKey) {
  return jwt.verify(token, publicKey, {
    algorithms: ["RS256"], // aldri la denne stå tom eller "any"
  });
}

// For HMAC-baserte webhooks (f.eks. Stripe-stil):
const crypto = require("crypto");

function verifyWebhookSignature(payload, signatureHeader, secret) {
  const expected = crypto
    .createHmac("sha256", secret)
    .update(payload, "utf8")
    .digest("hex");

  return crypto.timingSafeEqual(
    Buffer.from(expected),
    Buffer.from(signatureHeader)
  );
}

Legg merke til crypto.timingSafeEqual i HMAC-eksempelet. Å sammenligne signaturer med vanlig strenglikhet (===) åpner for timing-angrep, der en angriper kan gjette seg fram til riktig signatur byte for byte basert på hvor lang tid sammenligningen tar.

Test ytelsen i ditt eget system

Tallene i denne artikkelen kommer fra OpenSSL-benchmarks, Auth0s node-jsonwebtoken-tester og uavhengige JWT-målinger, men den eneste tallrekken som egentlig betyr noe for arkitekturbeslutningen din, er den du måler på din egen maskinvare med dine egne biblioteker. Forskjeller i CPU-generasjon, om SHA-NI-instruksjoner er tilgjengelige, og hvilken versjon av kryptografi-biblioteket som brukes, kan flytte tallene betydelig i begge retninger.

Den enkleste måten å verifisere tallene på er OpenSSLs innebygde speed-kommando, som er tilgjengelig på de fleste Linux- og macOS-systemer uten ekstra installasjon:

# Mål HMAC-SHA256-gjennomstrømming
openssl speed -evp sha256

# Mål RSA-2048 signering og verifisering
openssl speed rsa2048

# Mål ECDSA P-256 signering og verifisering
openssl speed ecdsap256

Output viser operasjoner per sekund direkte, og lar deg sammenligne resultatet mot tallene i denne artikkelen for å se hvor din egen maskinvare og OpenSSL-versjon plasserer seg. Hvis du bygger et JWT-basert system, er det også verdt å måle på applikasjonsnivå, ikke bare på ren kryptografi, siden JWT-biblioteker legger til overhead for parsing, header-håndtering og Base64-koding som ikke fanges opp av en ren OpenSSL-benchmark. Auth0s egen node-jsonwebtoken-benchmark, referert tidligere i artikkelen, er et godt eksempel på hvordan man setter opp en slik test med et faktisk bibliotek i produksjonskode, ikke bare den underliggende algoritmen isolert.

Et poeng verdt å ta med seg: forskjellen mellom HMAC og RSA blir mindre kritisk jo lenger unna signerings- og verifiseringsoperasjonen ligger fra den varme kodestien til systemet ditt. Et system som utsteder ti tokens i sekundet, merker ingen praktisk forskjell mellom HS256 og RS256. Et system som verifiserer hundretusenvis av forespørsler i sekundet mot et API-gateway-lag, kan derimot se en målbar forskjell i CPU-forbruk og dermed i antall serverinstanser som trengs, noe som gjør benchmarken relevant helt ned til infrastrukturkostnaden.

NIST-status og standarder i 2026

Standardene bak begge teknologiene er i bevegelse. NIST publiserte i juni 2024 et første offentlig utkast av SP 800-224, som flytter HMAC-spesifikasjonen ut av FIPS-serien og inn i en egen Special Publication, samtidig som den grunnleggende konstruksjonen beholdes uendret. I juni 2025 varslet NIST at de foreslår å trekke tilbake FIPS 198-1 til fordel for SP 800-224, med begrunnelsen at den gamle standarden er utdatert og bør oppdateres til å inkludere blokkstørrelser for SHA-3.

På signatursiden er FIPS 186-5 fra februar 2023 fortsatt gjeldende standard, og den godkjenner RSA, ECDSA og EdDSA som gyldige metoder for nye digitale signaturer. Sammen med SP 800-186, som definerer elliptiske kurve-parametere, danner dette grunnlaget for både RS256 og ES256 slik de brukes i JWT i dag. For nettverksenheter med krav om FIPS-validering er HMAC fortsatt den eneste godkjente algoritmen for meldingsautentiseringskoder, ifølge gjeldende DISA STIG-krav.

Post-kvante-perspektivet

Verken HMAC eller RSA/ECDSA er designet for en fremtid med kryptografisk relevante kvantedatamaskiner, men de er sårbare på svært ulike måter. HMAC, som er basert på hashfunksjoner, rammes bare av Grovers algoritme, som i teorien halverer sikkerhetsnivået fra 256-bit til effektivt 128-bit sikkerhet. Det er fortsatt trygt i praksis med dagens nøkkellengder. RSA og ECDSA derimot er begge sårbare for Shors algoritme, som i teorien bryter dem fullstendig gitt en tilstrekkelig kraftig kvantedatamaskin, ikke bare svekker dem gradvis. Dette er en av grunnene til at NIST har publisert egne post-kvante-standarder som ML-DSA (digitale signaturer) og ML-KEM (nøkkelutveksling) for organisasjoner som allerede nå planlegger en overgang bort fra RSA og ECDSA. Les mer i vår sammenligning av ML-DSA vs SLH-DSA og ML-KEM vs RSA.

Beslutningstabell: hvilken algoritme passer scenarioet ditt?

Hvis du fortsatt er usikker etter alt dette, kan følgende beslutningstabell brukes som en rask sjekkliste før du velger algoritme for et nytt system.

Scenario	Antall part(er) som verifiserer	Anbefalt algoritme
Webhook fra én tredjepartstjeneste til deg	Én (deg)	HMAC-SHA256
Intern mikrotjeneste-til-mikrotjeneste innenfor samme klynge	Få, kjente tjenester	HMAC-SHA256
Access-token for offentlig API med tredjepartsutviklere	Mange, ukjente tjenester	RS256 eller ES256
ID-token fra en identitetsplattform (SSO)	Mange forbrukende applikasjoner	RS256 eller ES256
Mobilapp som verifiserer tokens lokalt på enheten	Enkeltenheter med begrenset CPU	ES256
Høyvolum API-gateway med millioner av forespørsler i timen	Én gateway, men høy last	HMAC internt, RS256/ES256 ved utstedelse
System med krav om FIPS 140-validert MAC	Varierer	HMAC (FIPS 198-1/SP 800-224)

Legg merke til at mange reelle systemer havner i den nest siste raden: de bruker begge algoritmene samtidig, men til forskjellige formål i samme arkitektur. Det er ikke en kompromissløsning, det er rett og slett riktig bruk av verktøyet til riktig jobb.

Verdikt: hva bør du velge?

Basert på tallene over er det ikke ett riktig svar, men et klart mønster: velg HMAC når du kontrollerer begge ender av kommunikasjonen, altså webhooks mellom to kjente systemer eller intern tjeneste-til-tjeneste-trafikk i samme sikkerhetssone. Her vinner HMAC på alle målbare punkter, med opptil 150 ganger raskere signering ifølge Auth0s egne benchmarks, mindre signaturer, og enklere implementasjon, uten noen reell sikkerhetsulempe siden nøkkelen aldri forlater et lukket sett av parter.

Velg RS256 eller ES256 når tokenet skal verifiseres av flere uavhengige parter, altså offentlige API-er, identitetsplattformer og alt der en kompromittert verifiserende tjeneste ikke skal kunne utstede nye, gyldige tokens. Ytelseskostnaden, som er reell og målbar, er prisen du betaler for at ingen forbrukere av tokenet kan forfalske nye. ES256 er som regel et bedre valg enn RS256 for nye systemer i 2026, siden det gir tilsvarende sikkerhet med mindre signaturer og raskere signering, forutsatt at biblioteker og infrastruktur i økosystemet ditt støtter det fullt ut.

Uansett hvilken algoritme du velger: håndhev alltid en eksplisitt algoritme-allowlist på verifiseringssiden. Det er den ene endringen som stopper både alg=none-angrep og nøkkelforvirring, og den koster ingenting i ytelse.

Ofte stilte spørsmål

Er HMAC mindre sikkert enn RSA?

Nei, ikke i seg selv. HMAC-SHA256 gir tilsvarende kryptografisk styrke som RSA-2048 og ECDSA P-256 når det brukes riktig. Svakheten med HMAC ligger ikke i algoritmen, men i arkitekturen: alle som kjenner den delte hemmeligheten kan både signere og verifisere, noe som gjør det uegnet der mange uavhengige parter må verifisere uten å kunne forfalske.

Kan jeg bruke HMAC til JWT i en offentlig API?

Teknisk sett ja, men det anbefales sjelden. Så snart flere uavhengige tjenester eller tredjepartsutviklere skal verifisere tokenet, må de alle få den delte hemmeligheten, noe som gjør det umulig å garantere at ingen av dem kan utstede forfalskede tokens. RS256 eller ES256 løser dette ved å la kun utstederen ha den private nøkkelen.

Hvorfor er RSA-signering så mye tregere enn verifisering?

Fordi RSA-signering krever en operasjon med den private eksponenten, som normalt er et stort tilfeldig tall, mens verifisering bruker den offentlige eksponenten, som ofte er det lille, faste tallet 65537. Operasjoner med små eksponenter er langt raskere å beregne enn operasjoner med store eksponenter, derfor er RSA-verifisering typisk 20-30 ganger raskere enn RSA-signering.

Bør jeg bytte fra RS256 til ES256?

For nye systemer, ofte ja. ES256 gir tilsvarende sikkerhet som RS256 (faktisk nærmere RSA-3072-nivå) med mye kortere nøkler og signaturer, og raskere signering. Ulempen er at støtten i eldre biblioteker og systemer historisk har vært dårligere enn for RSA, så sjekk kompatibiliteten i hele kjeden din, inkludert eventuelle tredjeparts-SDK-er, før du migrerer eksisterende systemer.

Hva er alg=none-angrepet, og er det fortsatt relevant?

Ja, fortsatt svært relevant. Angrepet utnytter biblioteker som aksepterer alg: "none" i JWT-headeren og dermed hopper over signaturverifisering helt. Nyere sårbarheter som CVE-2026-27804, CVE-2026-28802 og CVE-2026-39413 viser at samme feilklasse fortsatt dukker opp i nye rammeverk. Løsningen er å alltid håndheve en eksplisitt algoritme-allowlist ved verifisering.

Koster RSA-signering mer i AWS KMS eller Azure Key Vault enn HMAC?

Prisen per operasjon er stort sett lik. AWS KMS fakturerer $1 per nøkkel i måneden uansett type, og $0,15 per 10 000 asymmetriske operasjoner. Den reelle kostnadsforskjellen kommer fra volumet: siden RSA er tregere enn HMAC i applikasjonskode, ender høyvolum-systemer ofte opp med å unngå KMS-kall per token og heller signere lokalt, uavhengig av hvilken algoritme de bruker.

Bruker Stripe og GitHub digitale signaturer eller HMAC for webhooks?

Begge bruker HMAC-SHA256. Stripe sender signaturen i Stripe-Signature-headeren med et tidsstempel og en HMAC-verdi, mens GitHub bruker X-Hub-Signature-256 med samme prinsipp. Dette er det klassiske eksempelet på når HMAC er riktig valg: en kjent avsender og en kjent mottaker som allerede har avtalt en delt hemmelighet.

Kan jeg bruke HMAC og RSA sammen i samme system?

Ja, og det er faktisk det vanligste mønsteret i praksis. Mange arkitekturer bruker HMAC for interne tjeneste-til-tjeneste-kall og webhook-verifisering fra eksterne partnere, samtidig som de bruker RS256 eller ES256 for JWT-er som utstedes til sluttbrukere og tredjepartsklienter. Poenget er å ikke blande de to innenfor samme verifiseringspunkt, siden det åpner for nøkkelforvirrings-angrep.

Hva er key rollover, og hvorfor gjør det RSA/ECDSA enklere å rotere?

Key rollover betyr at flere gyldige offentlige nøkler publiseres samtidig i et JWKS-endepunkt, hver identifisert med en unik kid-verdi. Det lar en identitetsplattform ta i bruk en ny privat nøkkel for signering uten å bryte verifisering av tokens som allerede er utstedt med den gamle nøkkelen. HMAC har ikke noe tilsvarende enkelt mønster, siden alle parter må ha nøyaktig samme hemmelighet til enhver tid.

Hvor lang bør en HMAC-hemmelighet være?

Minst 256 bit (32 byte) tilfeldig genererte data, tilsvarende sikkerhetsnivået til selve HMAC-SHA256-algoritmen. En kortere eller forutsigbar hemmelighet svekker hele signaturen uansett hvor sterk den underliggende hashfunksjonen er, siden en angriper da kan gjette eller brute-force-angripe nøkkelen i stedet for algoritmen.

Relatert dekning

Kilder: NIST FIPS 186-5 (Digital Signature Standard), NIST SP 800-224 (HMAC-utkast), Stripe webhook-dokumentasjon, GitHub webhook-dokumentasjon, OWASP Web Security Testing Guide (JWT), Auth0 signeringsalgoritmer, AWS KMS-priser, Azure Key Vault-priser, Google Cloud KMS-priser.

HMAC vs RSA-signaturer: 150x Raskere med Delt Nøkkel [2026]