mTLS vs OAuth2 client credentials: hvad skal du vælge?

Når to systemer skal autentificere sig over for hinanden uden en bruger involveret, er de to dominerende valg mTLS og OAuth2 client credentials. De løser samme problem på to forskellige lag, og de udelukker ikke hinanden. Her er forskellen, fordele og ulemper, og hvornår du bør kombinere dem.

Kort svar

mTLS autentificerer på transportlaget med et certifikat: klienten beviser sin identitet i selve TLS-handshaken, før noget HTTP overhovedet sendes. OAuth2 client credentials autentificerer på applikationslaget med en token: klienten henter en access token fra en authorization server og sender den i en Authorization-header. mTLS er stærkere mod token-tyveri og binder identiteten til transporten; OAuth2 er nemmere at integrere, skalere og styre fingradet. Mange seriøse setups kombinerer dem.

Hvordan hver enkelt fungerer

Med mTLS præsenterer klienten et certifikat under handshaken. Serveren validerer det mod en CA, og forbindelsen kommer kun i stand hvis certifikatet er gyldigt. Der er ingen separat token at hente eller udløbe undervejs — identiteten er forbindelsen.

Med OAuth2 client credentials udveksler klienten et client_id + client_secret (eller et signeret JWT) for en kortlivet access token:

curl -X POST https://auth.example.com/oauth2/token \
  -d "grant_type=client_credentials" \
  -d "client_id=service-a" \
  -d "client_secret=$SECRET" \
  -d "scope=payments:write"

# -> { "access_token": "eyJ...", "expires_in": 3600, "scope": "payments:write" }

Derefter sendes token'en med på hvert kald: Authorization: Bearer eyJ.... Token'en bærer scopes, der afgør hvad klienten må — det er fingradet autorisation indbygget.

Sammenligning

Egenskab	mTLS	OAuth2 client credentials
Lag	Transport (TLS)	Applikation (HTTP)
Identitetsbevis	Privat nøgle (sendes aldrig)	Token / delt secret
Fingradet autorisation	Skal bygges oven på	Indbygget via scopes
Sårbar for tyveri af bevis	Nej (nøglen forlader ikke klienten)	Ja (token kan stjæles og genbruges)
Rotation	Forny certifikat (kan automatiseres via ACME)	Roter secret / kortlivet token
Tilbagekaldelse	CRL/OCSP eller fjern fra trust	Tilbagekald token / secret

Styrker og svagheder

mTLS har den stærkeste binding: den private nøgle forlader aldrig klienten, så der er intet bevis at stjæle på vej over linjen. Til gengæld kræver det certifikat-distribution og -fornyelse, og fingradet autorisation skal bygges oven på identiteten.

OAuth2 er nemmere at integrere bredt og giver scopes og centraliseret kontrol ud af boksen, men en access token er en bærer-token: stjæler nogen den, kan de bruge den indtil den udløber. Korte levetider og sender-constrained tokens dæmper risikoen.

Det bedste fra begge: OAuth2 bundet til mTLS

De to udelukker ikke hinanden. RFC 8705 (OAuth 2.0 Mutual-TLS) binder en access token til klientens certifikat, så token'en kun kan bruges af den klient, der oprindeligt fik den — selv hvis token'en lækker. Du får OAuth2's scopes og centrale styring plus mTLS' stærke, ikke-overførbare binding. I praksis: mTLS til at bevise hvem, OAuth2-scopes til at afgøre hvad.

Hvad du vælger afhænger af miljøet

Internt service mesh / Zero Trust: mTLS er det naturlige valg og ofte allerede leveret af meshet. Se mTLS og Zero Trust.
Offentligt API til mange tredjeparter: OAuth2 client credentials skalerer bedre og er hvad partnere forventer.
Høj sikkerhed + mange integrationer: kombinér via OAuth2-mTLS-binding.

Uanset valget: certifikaterne skal overvåges

Vælger du mTLS — alene eller bundet til OAuth2 — får du certifikater på både server- og klientsiden, ofte fra interne CA'er, med hver sin udløbsdato. CertControl opdager og overvåger dem alle, validerer kæderne og advarer i god tid, så hverken et udløbet klientcertifikat eller en udløbet intern CA pludselig lukker jeres maskine-til-maskine-integrationer. Begynd med hvad er mTLS.

Ofte stillede spørgsmål

Hvad er den grundlæggende forskel på mTLS og OAuth2?

mTLS autentificerer på transportlaget med et certifikat (identiteten er bundet til TLS-forbindelsen), mens OAuth2 client credentials autentificerer på applikationslaget med en token, der sendes i en HTTP-header. Det ene er en del af forbindelsen, det andet ligger oven på den.

Er mTLS mere sikkert end OAuth2?

På ét punkt ja: den private nøgle forlader aldrig klienten, så der er intet bærer-bevis at stjæle. En OAuth2-access-token kan stjæles og genbruges indtil den udløber. Men OAuth2 giver til gengæld fingradet autorisation via scopes ud af boksen.

Kan jeg bruge mTLS og OAuth2 sammen?

Ja, og det er ofte den stærkeste løsning. RFC 8705 binder en OAuth2-token til klientens mTLS-certifikat, så token'en kun virker fra den klient der fik den. Du får både scopes og en ikke-overførbar binding.

Hvilken skalerer bedst til mange tredjeparter?

OAuth2 client credentials. Det er en velkendt standard, partnere allerede forstår, og det kræver ikke certifikat-distribution til hver enkelt integration. mTLS skinner mest i miljøer hvor du kontrollerer begge ender.

Hvad med rotation og tilbagekaldelse?

OAuth2-tokens er typisk kortlivede og fornyes automatisk; secrets roteres centralt. mTLS-certifikater fornyes (gerne via ACME) og kan tilbagekaldes via CRL/OCSP eller ved at fjerne dem fra trust. Begge kræver styring — og overvågning af udløb.

Se platformen Book demo