Hvilke krav bør stilles til API-sikkerhed og adgangsstyring?

Hvad skal kravene til API-sikkerhed og adgangsstyring dække?

API'er er rygraden i den digitale økonomi. De forbinder systemer, partnere, kunder og i stigende grad AI-løsninger. Ifølge DI Digital er de i dag kritisk infrastruktur: uden API'er stopper forretningen.

Anvendelserne er konkrete. ERP og produktionsanlæg udveksler driftsdata, output, fejl, produktionsordrer og styklister. Bygge- og anlægsprojekter udveksler tegninger, BIM-modeller, tidsplaner, mængder og ændringer mellem rådgivere, entreprenører og bygherre. Forsyningskæder udveksler ordrestatus, leveringstider, lagerbeholdning og fakturering.

Digitale platforme forbinder interne systemer med eksterne brugere og partnere. Hver forbindelse gør arbejdsgange hurtigere og udvider den samlede angrebsflade.

Kravene bør ikke kun handle om protokoller og kryptering. Netkant formulerer dem som de spørgsmål, en API-integration skal kunne svare på: hvilke data der passerer, hvem der får adgang, og hvad der sker, når noget fejler.

Dertil kommer ansvaret. Når en webshop sender kundeoplysninger til et ERP-system, eller et intranet henter medarbejderdata fra en ekstern løsning, handler det om, hvem der bærer ansvaret for dataadgang, datalagring og afhængigheder.

Sikkerhed skal afvejes mod anvendelighed. En integration med meget begrænset adgang og korte token-levetider kræver mere planlægning, men begrænser skaden ved et kompromitteret login. For mange kontrolpunkter kan omvendt gøre en enkel arbejdsgang skrøbelig.

Målet er dokumenteret og passende kontrol frem for maksimal friktion. Arbejdet skal ligge før udviklingen, fordi sikkerhed, GDPR og driftsstabilitet ikke kan lappes på efter go-live.

Krav til API-sikkerhed: Fakta og best practice

Prioriterede krav til API-sikkerhed (fra højest til lavest)

Kortlæg dataflow, klassificér data og begræns formålet

Før der udstedes API-nøgler eller skrives kode, skal dataflowet tegnes og dokumenteres: hvilke data skal flyttes, hvorfor, og mellem hvilke parter. Det skal fremgå, hvor data opstår, behandles og lagres, og hvem der kan tilgå dem undervejs. Det giver grundlag for både de tekniske valg og GDPR-vurderingen.

Klassificér data i mindst fire kategorier: offentlige, interne, fortrolige og personhenførbare oplysninger. Klassificeringen afgør, om data må sendes til en given modtager, og om der gælder særlige krav til kryptering, logning eller opbevaring.

Formålsbegrænsning skal være synlig i både kravspecifikation og kode. Et API-kald bør kun indeholde de felter, formålet kræver: en integration, der kun skal opdatere lagerstatus, behøver ikke adgang til kundens navn, e-mailadresse eller ordrehistorik; og hvis en leverandør kun skal modtage et kundenummer og en leveringsstatus, må kaldet ikke indeholde hele kundeprofilen. Jo færre data der sendes, jo mindre er risikoen ved fejl, misbrug og kompromittering.

Adskil identitet og autorisation med OAuth 2.0 og OIDC

Adskil de to spørgsmål: hvem er brugeren eller klienten, og hvad må vedkommende få adgang til. OAuth 2.0 er en autorisationsprotokol, der giver en applikation adgang til beskyttede ressourcer på vegne af en bruger uden at kende brugerens kodeord, men protokollen siger intet om, hvem brugeren er. OpenID Connect (OIDC) er et identitetslag oven på OAuth 2.0, som tilføjer et standardiseret svar på, hvem brugeren er, og hvordan vedkommende blev autentificeret. Microsoft beskriver forskellen tilsvarende: OIDC udfører godkendelse og bekræfter, at brugeren er den, de udgiver sig for at være, mens OAuth 2.0 godkender, hvilke systemer brugerne har adgang til.

Stil krav til ID-tokenet: det er en JWT, og det skal være signeret. Fem claims er obligatoriske — iss (udsteder), sub (unikt bruger-id hos udstederen, som aldrig genbruges til en anden person), aud (skal indeholde din egen client_id), exp (udløbstid) og iat (udstedelsestid). Kontrollen af signaturen og af aud hører hjemme på serveren; flytter man den ud i browseren, er det brugeren selv, der afgør, hvad der bliver godkendt.

En OIDC-forespørgsel skal indeholde scope-værdien openid. Mangler den, er adfærden udefineret, og man sidder reelt tilbage med en almindelig OAuth-udveksling uden noget udsagn om identitet. Scope bør samtidig begrænses, så klienten kun får adgang til det nødvendige.

I miljøer med en central identitetsudbyder kan organisationen bruge et IAM-system som Microsoft Entra ID som primær godkender. Derefter kan organisationen bruge OIDC til at overføre godkendelsen til andre apps. Så skal brugeren kun logge på én gang for at få adgang til flere apps.

Stil krav til tokens, flows og PKCE

For nye integrationer bør Authorization Code Flow være standardvalget. Implicit Flow frarådes i dag, fordi tokenet leveres direkte i browserens adresselinje og dermed havner i historik, logfiler og eventuelle referrers. OAuth 2.1 fjerner officielt Implicit Flow og Resource Owner Password Credentials Grant, og Authorization Code Flow med PKCE er det eneste anbefalede flow for webapplikationer fremadrettet.

PKCE (RFC 7636) lukker et konkret hul i mobilapps og enkeltsideapplikationer. Klienten danner en tilfældig code_verifier på 43 til 128 tegn og sender code_challenge = BASE64URL(SHA256(verifier)) med metoden S256; først når autorisationskoden skal veksles til et token, afslører klienten den oprindelige værdi. Uden PKCE kan en ondsindet app på samme enhed opsnappe autorisationskoden og indløse den; med PKCE er koden værdiløs for den, der ikke kender verifieren. Kravet bør gælde alle offentlige klienter, ikke kun mobilapps.

Access tokens bør være kortvarige og kun indeholde det nødvendige — typisk et bruger-ID og en udløbstid. Claims i ID-tokenet er et bevidst valg.

I et aldersverifikationsflow kan tjenesten bede om scope openid age_verify:16. Svaret kommer i claimet idbrokerdk_age_verified med værdien "16:true" eller "16:false", uden at hverken CPR-nummer eller fødselsdato udleveres.

Skal der derimod laves KYC, hvor identiteten skal kendes, kommer navn og CPR-nummer med i svaret. Samme protokol kan altså give vidt forskellige mængder personoplysninger, og den forskel skal kunne forklares, hvis nogen spørger, hvorfor I opbevarer det, I opbevarer.

Roller, scopes og mindste privilegium i praksis

Mindste privilegium betyder, at hver integration og hver tredjepart kun får de roller og scopes, opgaven kræver. Permanente eller brede adgange bør undgås: hvis en tredjepart får permanent adgang til et kundesystem, eller hvis data kopieres til en tjeneste uden for den aftalte databehandlerkæde, kan konsekvensen blive langt større end en fejlmeddelelse i et logsystem.

Korte token-levetider og begrænsede rettigheder kræver mere planlægning — der skal være styr på fornyelse, og på hvad klienten gør, når et token udløber — men de begrænser skaden, hvis et login kompromitteres. For mange kontrolpunkter kan omvendt gøre en enkel arbejdsgang skrøbelig. Kravet bør derfor formuleres som dokumenteret og passende kontrol, ikke som maksimal friktion.

I praksis: start med det mindste scope, hvor identitet er nødvendig, tilføj kun de scopes og claims, formålet kræver, og undgå brede administrativt prægede scopes til integrationer, der kun skal læse en afgrænset ressource. Roller og scopes bør stå i kravspecifikationen med en begrundelse for hver enkelt.

Checkliste: Sikker API-adgangsstyring i praksis

Rate limiting, logning og overvågning som adgangskrav

Rate limiting, overvågning og logning er adgangskrav, ikke driftspynt. Ifølge DI Digital er API'er attraktive mål, fordi de ofte eksponerer forretningslogik direkte, anvender svag eller forkert autorisation, mangler rate limiting og overvågning og bliver glemt i klassiske sårbarhedsscanninger. Angriberne behøver ikke længere bryde gennem perimeteren — de logger ind eller kalder API'er.

Konsekvensen er, at datatyveri, misbrug af funktioner og systematisk automatiseret udnyttelse kan ske uden at udløse traditionelle alarmer. Overvågningen skal derfor kunne opdage netop det: unormale kaldemønstre, gentagne autorisationsfejl og brug af funktioner uden for det normale. Logning af autorisationsfejl bør være et selvstændigt krav, fordi gentagne fejl kan være det første synlige tegn på, at nogen prøver sig frem.

Kravet vokser, efterhånden som AI kommer ind i billedet: langt de fleste AI-løsninger er ifølge DI Digital afhængige af API'er til dataadgang, modelkald og integration i forretningsprocesser, så et kompromitteret API-endpoint er ikke kun en datahændelse, men rammer de processer, der er bygget ovenpå.

Krav til fejlhåndtering, afhængigheder og drift

Et eksplicit krav bør være: hvad sker der, når noget fejler? Det dækker fejlmodus i det enkelte kald, hvad der sker med data, der er undervejs, hvor de ender, hvem der har ansvaret, og hvilke afhængigheder der udløses, hvis en part er nede.

Dataflowet fra kortlægningen er den samme oversigt, der bruges her: hvor data behandles og lagres, og hvem der kan tilgå dem undervejs, er præcis de oplysninger, fejlhåndteringen skal bygge på. Afhængigheder hører med i kravene, fordi en integration ikke kun forbinder to systemer, men også to organisationer.

En tredjepart med permanent adgang eller kopiering af data til en tjeneste uden for den aftalte databehandlerkæde er et fejlscenarie, der ikke giver en fejlmeddelelse i et logsystem, men et spørgsmål om ansvar. Integrationen bør ikke betragtes som en teknisk detalje hos udvikleren eller systemleverandøren. Den træffer beslutninger om dataadgang, datalagring, ansvar og afhængigheder, og sikkerhed, GDPR og driftsstabilitet skal derfor tænkes ind fra første arkitekturskitse — kravene kan ikke lappes på efter go-live.

Særlige krav ved dansk offentlig adgangsstyring

I dansk offentlig sammenhæng skal valg af standard og applikationstype dokumenteres. Leverandører af it-systemer, der bruger Fælleskommunal Adgangsstyring for brugere (Context Handler), kan nu vælge at bruge OpenID Connect ved log-in/log-out af brugere; SAML 2.0 er fortsat understøttet af Context Handler. Når et nyt it-system af typen "brugervendt system" oprettes i Fælleskommunalt Administrationsmodul, skal leverandøren vælge applikationstype — "SAML 2.0" eller "OIDC" — afhængigt af, hvilken standard systemet understøtter.

Praktiske konsekvenser at tage højde for: brugervendte systemer, der var oprettet i Administrationsmodulet inden den 15. august 2026, er automatisk blevet registreret med applikationstypen SAML 2.0. En applikationstype kan ændres fra SAML 2.0 til OIDC, men ikke den modsatte vej. It-systemer af typerne "Anvendersystem", "Identity Provider" og "Serviceudbyder" er ikke påvirket af ændringen.

Ved brug af OIDC skal signeringsalgoritmen PS256 anvendes i kommunikationen med Context Handler. Der har været en fejl i oplysningerne om signeringsalgoritme i /.well-known/openid-configuration, hvor der stod RS256 i stedet for PS256; fejlen blev rettet i eksternt testmiljø og forventedes rettet i produktionsmiljøet den 29. august 2026. Kravet til integrationen er derfor ikke blot at læse discovery-dokumentet, men at verificere signeringsalgoritme og metadata mod vejledningen for det konkrete miljø.

SAML 2.0 vs OpenID Connect i dansk offentlig adgangsstyring

Omsæt kravene til kravspecifikation, ansvar og governance

Kravene skal skrives ind i kravspecifikation, arkitektur og kontrakt med leverandører frem for at ligge i en udviklers hukommelse.

Formålsbegrænsning skal være synlig i både kravspecifikation og kode. For hvert API-kald bør der stå, hvilke felter der må sendes, og hvilke scopes der kræves. Det bør også stå, hvor længe tokens lever, hvor data lagres, hvad der logges, hvor længe det opbevares, og hvem der er ansvarlig for hver del.

Governance-delen består i, at kravene kan revideres og følges op. Det kræver en ejer pr. integration og en oversigt over, hvilke API'er der er eksponeret internt og eksternt, hvilke data og funktioner de giver adgang til, og hvordan identitet og autorisation håndteres. Uden den oversigt bliver API-sikkerhed et udvikleranliggende, og når integrationen først er i drift, er der ingen, der kan svare på spørgsmålene.

Domsdatabasen illustrerer, hvordan en API-udstiller kan sætte betingelser for adgang. Adgangen kræver en ansøgning, og der er ikke krav til et specifikt teknisk set-up. Ansøgeren skal have et anerkendelsesværdigt formål, og der skal afgives en tro og love-erklæring.

API'et er baseret på Restful Services og giver adgang til to download-services — enten metadata og dokumenter fra en bruttoliste eller ændringer i databasen foretaget fra en angiven dato. Egne krav til eksterne partnere bør formuleres på samme måde: som efterprøvelige betingelser, der kan trækkes tilbage, ikke som en teknisk engangsopsætning.

Faser i sikker API-integration – fra planlægning til drift