Min første møte med Maskinporten – fra forvirring til forståelse
Jeg husker første gang jeg hørte ordet «Maskinporten» på et IT-møte i fjor. Satt der og nikket klokt mens alle snakket om API-er og tokens, men innvendig tenkte jeg «hva i alle dager er dette egentlig?» Det tok meg flere måneder å skjønne hvordan Maskinporten fungerer på ordentlig, og ærlig talt – det var både mer komplisert og enklere enn jeg først trodde.
Etter å ha jobbet med dette systemet i over et år nå, kan jeg trygt si at Maskinporten er en av de viktigste byggesteinene i Norges digitale infrastruktur. Men altså, det er ikke akkurat noe man lærer på barneskolen! Første gang jeg skulle implementere det i praksis, føltes det som å løse et puslespill hvor halvparten av brikkene manglet instruksjonsbok.
Maskinporten er i bunn og grunn Digitaliseringsdirektoratets løsning for hvordan maskiner (datamaskiner, servere, systemer) kan bevise hvem de er når de skal snakke sammen. Tenk på det som et ID-kort for digitale systemer – bare mye mer avansert og sikkert enn det. Når systemet ditt skal hente informasjon fra for eksempel Skatteetaten eller NAV, må det først bevise at det har lov til det gjennom Maskinporten.
Det geniale med løsningen er at den erstatter gamle, usikre metoder som API-nøkler og passord med noe som faktisk er trygt nok for offentlige tjenester. Men jeg skal være ærlig – læringskurven var bratt. Jeg bommet helt første gang jeg prøvde å sette opp en integrasjon, og det tok meg tre uker å forstå hvorfor tokenet mitt ikke fungerte (spoiler: jeg hadde glemt å registrere riktig scope).
Teknisk arkitektur – hvordan systemet faktisk henger sammen
La meg forklare hvordan Maskinporten fungerer på teknisk nivå, basert på det jeg har lært gjennom å implementere det i forskjellige prosjekter. Systemet bygger på OAuth 2.0 og OpenID Connect standarder, men med en spesiell vri som gjør det egnet for maskin-til-maskin-kommunikasjon.
Kjernen i systemet er det som kalles «JWT Bearer Grant» – et fancy navn for en metode hvor systemet ditt lager et digitalt sertifikat som beviser hvem det er. Jeg pleier å forklare det slik til kollegaer: tenk deg at du skal inn på en eksklusiv klubb, men i stedet for å vise fram ID-kortet ditt, så underskriver du en lapp med spesiell blekk som bare du har. Dørvakten kan sjekke underskriften og vite at det var deg som skrev den.
I praksis fungerer det sånn at systemet ditt har et kryptografisk nøkkelpar – en privat nøkkel som kun du har, og en offentlig nøkkel som Maskinporten kjenner til. Når du skal hente data, lager systemet ditt en JWT (JSON Web Token) som det signerer med den private nøkkelen. Maskinporten verifiserer signaturen med den offentlige nøkkelen, og hvis alt stemmer, får du tilbake et access token.
Det som gjorde meg forvirret i starten var at det faktisk skjer i to separate steg. Først sender du JWT-en til Maskinporten for å få et access token. Deretter bruker du dette access token-et til å kalle API-et du egentlig vil nå. Det føles litt som å måtte vise ID to ganger, men det gir mening sikkerhetssmessig.
Sertifikater og nøkkelhåndtering
En ting jeg lærte på den harde måten: sertifikatbehandling er ikke noe å ta lett på. Maskinporten støtter både virksomhetssertifikater og selv-signerte sertifikater for testing. Jeg brukte månedsvis på å forstå forskjellen, og hvorfor produksjonsmiljøet krevde et ordentlig virksomhetssertifikat fra en godkjent Certificate Authority.
Virksomhetssertifikatet koster penger – vi betalte cirka 3000 kroner for vårt fra Buypass, og det måtte fornyes hvert år. Det var litt surt første gang regningen kom, men jeg skjønner nødvendigheten nå. Det er forskjell på et hjemmelaget sertifikat og et som faktisk beviser at vi er den bedriften vi påstår å være.
Når det gjelder nøkkellagring, har jeg gjort både riktige og gale valg. Første prosjekt la vi sertifikatet rett i kodelageret (facepalm!), før vi lærte om Azure Key Vault og lignende løsninger. Nå bruker vi alltid dedikerte nøkkelhåndteringstjenester – det koster litt ekstra, men søvnen min er verdt det.
Registrering og oppsett – min steg-for-steg-erfaring
La meg dele prosessen jeg går gjennom når jeg setter opp en ny Maskinporten-integrasjon, basert på alle gangene jeg har gjort dette nå. Det er faktisk blitt ganske rutinert, men første gang var det… utfordrende.
Steg 1: Forberedelser og planlegging
Før jeg i det hele tatt begynner med selve registreringen, bruker jeg alltid tid på å kartlegge nøyaktig hva vi trenger tilgang til. Dette lærte jeg etter at vi måtte gjøre om registreringen tre ganger fordi vi ikke hadde tenkt gjennom alle use case-ene på forhånd.
Jeg lager alltid en liste over hvilke API-er vi skal integrere mot, hvilke scopes (tilganger) vi trenger, og om vi skal dele denne integrasjonen med andre systemer. Sist jeg gjorde dette for en kunde, viste det seg at de trengte tilgang til både Altinn og Skatteetaten, men hadde bare nevnt Altinn i opprinnelig kravspesifikasjon.
Steg 2: Selvbetjeningsportalen
Registreringen skjer i Digitaliseringsdirektoratets selvbetjeningsportal på samarbeid.digdir.no. Første gang jeg så denne portalen tenkte jeg «dette ser jo enkelt ut!» – men det var før jeg begynte å fylle ut skjemaene.
Du må logge inn med virksomhetens ID-porten, og personen som gjør registreringen må ha riktige fullmakter. Her bommet jeg første gang – jeg antok at jeg som utvikler kunne registrere på vegne av kunden, men det måtte faktisk gjøres av noen med daglig leder-rettigheter eller spesielle IT-fullmakter.
Registreringsprosessen tar vanligvis 2-3 arbeidsdager hvis alt er i orden. Men jeg har opplevd at det tar opp til to uker hvis Digitaliseringsdirektoratet har spørsmål til søknaden. Protip: vær ekstrem nøyaktig i beskrivelsen av hva dere skal bruke tilgangen til.
Steg 3: Teknisk implementasjon
Her kommer den delen jeg elsker og hater samtidig – selve kodingen. Jeg har implementert Maskinporten-integrasjoner i .NET, Java og Python nå, og hver gang lurer jeg på hvorfor jeg ikke dokumenterte bedre sist gang.
For .NET-prosjektar bruker jeg gjerne NuGet-pakken «DigDir.ApiClients.Maskinporten» som gjør mye av det tunge løftet. Men jeg husker første gang jeg prøvde å rulle min egen implementering – det tok meg fire dager å debugge hvorfor JWT-signaturen min ikke ble akseptert (spoiler: feil algoritme).
| Programmeringsspråk | Anbefalt bibliotek | Vanskelighetsgrad | Min erfaring |
|---|
| .NET | DigDir.ApiClients.Maskinporten | Lett | Fungerer som smurt, god dokumentasjon |
| Java | Nimbus JOSE + JWT | Middels | Mer kode, men fleksibelt |
| Python | PyJWT + Cryptography | Middels | Mange eksempler på GitHub |
| Node.js | node-jose | Vanskelig | Få eksempler, mye trial-and-error |
Sikkerhet og beste praksis – lærdommer fra virkeligheten
Gjennom årene har jeg sett (og dessverre gjort) en del sikkerhetsmessige tabber når det kommer til Maskinporten. La meg dele de viktigste lærdomsene mine, så du slipper å gjøre de samme feilene.
Sertifikathåndtering som ikke holder deg våken om natta
Det mest kritiske jeg har lært er at sertifikater har forfallsdato, og de kommer alltid til å expire på det mest uheldige tidspunktet. Jeg var på ferie på Kreta da sertifikatet til en kritisk integrasjon utløp, og måtte bruke halve dagen på hotellets wifi for å fikse det.
Nå har jeg alltid kalenderpåminnelser seks måneder, tre måneder og en måned før sertifikater utløper. Og backup-rutiner. Og helst en ekstra person på teamet som vet hvordan man fornyer dem. Litt paranoid? Kanskje. Men jeg har sovet bedre siden.
For lagring av sertifikater bruker vi aldri lenger filsystem eller kode-repositories. Azure Key Vault har blitt min go-to løsning, selv om det koster litt ekstra. AWS Secrets Manager og HashiCorp Vault er også gode alternativer hvis du er i et annet økosystem.
Token-håndtering og caching
En ting som overrasket meg første gang var hvor kort levetid access tokens fra Maskinporten har – bare 120 sekunder! Det betyr at du ikke kan cache dem særlig lenge, og du må være forberedt på å hente nye tokens ofte.
Jeg pleier å implementere token refresh automatisk når tokens er 30 sekunder fra å utløpe. Dette har reddet meg flere ganger når API-kall tar lenger tid enn forventet. Og alltid, ALLTID ha retry-logikk hvis token-forespørselen feiler. Nettverk er upålitelig, det har jeg lært.
Logging og overvåking
Fra sikkerhetsperspektiv er det viktig å logge alle Maskinporten-forespørsler, men pass på at du ikke logger sensitive data som tokens eller sertifikat-innhold. Jeg har sett systemer som logget hele JWT-payloaden, noe som er både unødvendig og potensielt farlig.
Det jeg logger er:
- Tidspunkter for token-forespørsler
- Success/failure status
- Hvilke scopes som ble forespurt
- Client ID (ikke client secret!)
- Feilkoder hvis noe går galt
Og så har jeg satt opp alerts hvis token-forespørsler begynner å feile konsekvent. Det har hjulpet meg å oppdage problemer før brukerne merker dem.
API-integrasjoner og praktisk bruk
Nå kommer vi til det som egentlig er hele poenget med Maskinporten – å få tilgang til de offentlige API-ene vi trenger. Jeg har integrert mot det meste nå: Altinn, Skatteetaten, NAV, Brønnøysundregistrene, og flere andre. Hver integrasjon har sine særegenheter, men grunnprinsippet er det samme.
Altinn 3 – den mest vanlige integrasjonen
Altinn er ofte den første integrasjonen folk implementerer, og det var min også. Det som gjorde meg forvirret i starten var at Altinn har sitt eget lag med autorisasjon oppå Maskinporten-tokenet. Du må ikke bare bevise hvem du er (Maskinporten), men også at du har lov til å gjøre det du vil (Altinn-autorisasjon).
I praksis betyr det at selv om du får et gyldig access token fra Maskinporten, kan du fortsatt få 403 Forbidden fra Altinn-API-et hvis du ikke har riktige rettigheter satt opp i Altinn. Det tok meg en hel dag å skjønne det første gang – jeg trudde det var feil med Maskinporten-tokenet mitt.
For Altinn-integrasjoner pleier jeg alltid å starte med å teste mot deres TT02-miljø (testmiljø). De har gode testdata der, og du kan rote deg bort uten å påvirke produksjonsdata. Protip: opprett egen testorganisasjon med Tenor-data for testing – ikke bruk ekte organisasjonsnummer.
Skatteetaten – presisjon er viktig
Skatteetaten sine API-er er blant de mest stabile jeg har jobbet med, men de er også ganske strenge på formatet. Første gang jeg kalte Folkeregisteret-API-et, fikk jeg 400 Bad Request i timevis før jeg skjønte at datoformatet måtte være nøyaktig ISO 8601 med timezone.
Det som er fint med Skatteetaten er at de har ekstremt god dokumentasjon og mange kodeeksempler. Jeg pleier alltid å starte der når jeg skal lære et nytt API. Utviklerportalen deres på skatteetaten.github.io er gull verdt.
En ting å være oppmerksom på: Skatteetaten har ganske strenge rate limits på noen av API-ene sine. Vi måtte implementere køsystem for masseoppslag etter å ha blitt throttlet første gang vi prøvde å hente data for 10 000 personer på rad.
Brønnøysundregistrene – mange muligheter
Enhetsregisteret, Regnskapsregisteret, Konkursregisteret – Brønnøysund har mange nyttige API-er som alle bruker Maskinporten for autentisering. Jeg har brukt disse mest til å verifisere firmaopplysninger og hente regnskapsdata.
Det som er praktisk med Brønnøysund sine API-er er at mange av dem også er tilgjengelige uten Maskinporten (med begrensninger), så du kan teste logikken din før du setter opp all autentiseringen. Men for produksjonsbruk vil du alltid ha Maskinporten for å få høyere rate limits og tilgang til mer data.
Feilsøking og vanlige problemer
Etter hundrevis av timer med Maskinporten-debugging har jeg samlet en mental liste over de mest vanlige problemene og hvordan løse dem. La meg dele de som har tatt mest tid fra livet mitt.
JWT-signatur problemer
Dette er klassikeren som alle støter på først eller siden. Maskinporten returnerer «Invalid signature» og du sitter der og lurer på hva som gikk galt. Jeg har gjort denne feilen så mange ganger at jeg nesten kan løse den i søvne nå.
De vanligste årsakene jeg har sett:
- Feil signatur-algoritme (må være RS256, ikke HS256)
- Feil timestamp-format i JWT claims
- Klokka på serveren går feil (mer enn 5 minutter avvik)
- Bruker feil sertifikat (test vs prod)
- Sertifikatet har utløpt
For punkt 3 – klokkesynkronisering – det var et problem jeg aldri hadde tenkt på før jeg opplevde det. En av våre servere hadde gått 8 minutter feil, og Maskinporten avviste alle forespørslene våre. Nå sjekker jeg alltid systemklokka som første steg når noe mystisk skjer.
Scope og tilgangsproblemer
«Insufficient scope» er en annen feilmelding jeg har blitt for godt kjent med. Det skjer når du prøver å kalle et API uten å ha riktig scope registrert i Maskinporten-integrasjonen din.
Problemet er at det ikke alltid er intuitivt hvilke scopes du trenger. For eksempel, for å hente data fra Altinn sitt REST API trenger du «altinn:serviceowner/instances.read», men for å sende inn data trenger du «altinn:serviceowner/instances.write». Logisk nok, men ikke alltid opplagt når du leser API-dokumentasjonen.
Jeg pleier nå å starte med å liste opp alle operasjonene systemet skal kunne gjøre, så slå opp hvilke scopes som kreves for hver. Og så legger jeg på litt ekstra «for sikkerhets skyld» – det er enklere å ha for mange scopes enn for få.
Nettverksproblemer og timeout
Maskinporten kjører i skyen og er avhengig av internettforbindelse. Det høres selvfølgelig ut, men jeg har opplevd problemer med firewalls, proxy-servere og DNS som gjorde at forespørslene aldri nådde fram.
Spesielt utfordrende var en kunde som hadde meget streng utgående firewall. Vi måtte whiteliste alle IP-adressene til Maskinporten, og når de endret infrastruktur sin sluttet integrasjonen å fungere. Nå anbefaler jeg alltid å teste nettverkstilgang som et eget punkt før man begynner å kode.
For timeout-håndtering bruker jeg alltid minst 10 sekunder timeout på Maskinporten-kall, og helst 15-20 sekunder. API-ene kan være trege av og til, spesielt når det er mye trafikk.
Kostnader og ressursbruk – det skjulte regnestykket
En ting som kom som en overraskelse for meg var at selv om Maskinporten i seg selv er gratis å bruke, så kommer det noen skjulte kostnader som du bør regne med. La meg dele hva jeg har erfart når det gjelder den økonomiske siden.
Sertifikatkostnader
Som jeg nevnte tidligere koster virksomhetssertifikater penger. Vi bruker Buypass som leverandør, og prisen ligger på rundt 2500-3500 kroner per år avhengig av hvilken type sertifikat du velger. For større bedrifter kan det være verdt å investere i EV-sertifikater (Extended Validation) som koster mer, men gir høyere tillit.
Noen velger å gå for Commfides eller andre leverandører. Jeg har testet begge, og funkjonsmessig er det ikke så mye forskjell. Buypass har kanskje litt bedre kundeservice etter min erfaring, men det kan variere.
Utviklings- og vedlikeholdstid
Her er noe mange undervurderer: tiden det tar å utvikle og vedlikeholde Maskinporten-integrasjoner. For en enkel integrasjon kan jeg regne med 3-5 dager utvikling for en erfaren utvikler. Men det inkluderer ikke testing, feilsøking og dokumentasjon.
For komplekse integrasjoner mot flere API-er kan det fort bli 2-3 uker. Og så kommer vedlikehold på toppen – sertifikatfornyelse, håndtering av API-endringer, oppdatering av biblioteker. Jeg pleier å budsjettere med 1-2 dager per kvartal for vedlikehold av hver integrasjon.
Infrastrukturkostnader
Hvis du bruker sky-tjenester som Azure Key Vault eller AWS Secrets Manager for sertifikatlagring, koster det ekstra. For Azure Key Vault snakker vi om rundt 200-500 kroner per måned avhengig av bruk. Ikke store beløp, men de summerer seg hvis du har mange integrasjoner.
Overvåking og logging koster også. Vi bruker Application Insights i Azure, og det kan fort bli 1000-2000 kroner per måned for et system med mye API-trafikk. Men jeg synes det er verdt det for å kunne debugge problemer raskt.
Fremtidige utviklinger og min prognose
Etter å ha fulgt Maskinporten siden de tidlige dagene, har jeg noen tanker om hvor ting er på vei. Digitaliseringsdirektoratet har vært ganske åpne om roadmap-en sin, og jeg følger med på utviklingen gjennom deres GitHub-repository og tekniske fora.
Nye funksjonaliteter på vei
En ting jeg ser frem til er bedre støtte for API-nøkler i kombinasjon med Maskinporten. Akkurat nå er det enten-eller, men jeg skjønner at de jobber med hybride løsninger som kan gi det beste fra begge verdener.
Jeg har også hørt rykter om at de skal forbedre utvikleropplevelsen med bedre testverktøy og debugging-muligheter. Som en som har brukt utallige timer på å debugge JWT-tokens, kan jeg ikke få dette fort nok!
Internasjonale standarder
Det som imponerer meg med Maskinporten er hvor godt det følger internasjonale standarder. OAuth 2.0 og OpenID Connect er kjent teknologi for de fleste utviklere, så det er ikke som å lære et helt nytt system.
Jeg tror vi kommer til å se mer harmonisering med EU sine eIDAS-standarder fremover. Det kan bety enklere integrasjoner med europeiske tjenester, noe som blir stadig viktigere i en digitalisert verden.
Alternativer og når Maskinporten ikke passer
Selv om jeg er stor fan av Maskinporten, er det ikke alltid riktig løsning for alle situasjoner. La meg dele noen scenarioer hvor andre alternativer kan være bedre.
Interne system-til-system integrasjoner
Hvis du bare skal integrere mellom dine egne systemer, kan Maskinporten være overkill. For interne integrasjoner holder det ofte med API-nøkler eller mTLS (mutual TLS). Vi har fortsatt flere interne API-er som bruker enkle bearer tokens, og det fungerer helt fint.
Men hvis dataene er sensitive eller systemene er kritiske, kan det være verdt å bruke Maskinporten-lignende sikkerhet også internt. Det kommer an på risikovurderingen din.
Enkle offentlige API-er
Noen API-er har ikke behov for Maskinporten-nivå sikkerhet. Værmeldingen fra Meteorologisk institutt, for eksempel, er åpen for alle og trenger ikke autentisering i det hele tatt. Andre API-er kan klare seg med enkel API-nøkkel registrering.
Legacy-systemer
Det er også situasjoner hvor gamle systemer ikke kan oppgraderes til å støtte moderne autentiseringsmetoder. Da kan man være nødt til å bruke API-gateway eller proxy-løsninger som håndterer Maskinporten-integrasjonen på vegne av det gamle systemet.
Praktiske eksempler fra virkeligheten
La meg dele noen konkrete case jeg har jobbet med, anonymisert selvfølgelig, men som viser hvordan Maskinporten brukes i praksis.
Case 1: Regnskapsystem med Altinn-integrasjon
En regnskapsfører jeg hjalp trengte å hente inn alle regnskapsdata fra Altinn automatisk i stedet for å laste ned hver enkelt fil manuelt. Vi satte opp en nattlig batch-jobb som bruker Maskinporten for å autentisere mot Altinn sitt REST API.
Systemet henter data for alle klientene hennes (med deres samtykke selvsagt), og parser regnskapsdataene inn i regnskapssystemet. Det som tidligere tok hennes assistent hele dagen å gjøre manuelt, skjer nå automatisk på 15 minutter hver natt.
Utfordringen var å håndtere at hun har klienter med forskjellige autorisasjoner i Altinn. Vi måtte implementere feilhåndtering som skipper klienter hun ikke har tilgang til, uten å stoppe hele prosessen.
Case 2: HR-system med Folkeregister-oppslag
Et HR-system trengte å verifisere personopplysninger mot Folkeregisteret når nye ansatte registreres. I stedet for å stole på at folk skriver inn riktig navn og adresse, gjør systemet nå automatisk oppslag mot Skatteetaten sine API-er.
Det interessante med denne implementasjonen var personvern-aspektet. Vi måtte være ekstra nøye med logging og dataminimering, siden vi håndterer sensitive personopplysninger. Systemet henter bare de feltene som trengs, og sletter forespørselslogger etter 30 dager.
Case 3: Økonomisystem med multiple integrasjoner
Den mest komplekse implementasjonen jeg har gjort var for et økonomisystem som trengte integrasjoner mot Altinn, Skatteetaten, Brønnøysundregistrene og NAV. I stedet for å lage separate Maskinporten-integrasjoner for hver, brukte vi én integrasjon med alle de nødvendige scopes.
Det smarte med denne tilnærmingen var at vi kunne gjenbruke samme access token for alle API-kallene, så lenge de var innenfor token-ets levetid. Men det krevde mer kompleks scope-håndtering og feilhåndtering.
Ofte stilte spørsmål basert på min erfaring
Hvor lang tid tar det å komme i gang med Maskinporten?
Basert på prosjektene mine: regn med 1-2 uker fra registrering til du har en fungerende integrasjon. Det inkluderer ventetid på godkjenning fra Digitaliseringsdirektoratet (2-3 dager), anskaffelse av sertifikat (kan ta noen dager), og utvikling/testing. Hvis du er heldig og alt går på skinner, kan du gjøre det på en uke.
Kan jeg bruke samme Maskinporten-integrasjon for flere systemer?
Teknisk sett ja, men jeg anbefaler det ikke. Hver integrasjon bør helst representere ett system eller én tjeneste. Det gjør det enklere å håndtere tilganger, feilsøking og sikkerhet. Vi gjorde feilen med å dele integrasjon mellom systemer en gang, og da ble det kaos når vi skulle revoke tilganger.
Hva skjer hvis sertifikatet mitt utløper?
Da stopper alle API-kall som bruker det sertifikatet å fungere umiddelbart. Jeg har opplevd det, og det er ikke gøy. Derfor har jeg nå automatiske påminnelser måneder i forveien. Du kan oppdatere sertifikatet i selvbetjeningsportalen uten å måtte registrere integrasjonen på nytt.
Kan jeg teste Maskinporten uten å betale for sertifikat?
Ja! Maskinporten har eget testmiljø (ver2.maskinporten.no) hvor du kan bruke selv-signerte sertifikater. Jeg bruker alltid testmiljøet først for å verifisere at alt fungerer før jeg går over til produksjon. Men husk at test-miljøet bruker andre API-endepunkter enn produksjon.
Hvor mange API-kall kan jeg gjøre med Maskinporten?
Maskinporten selv har ganske generøse rate limits (jeg har aldri truffet dem), men de underliggende API-ene du kaller har sine egne begrensninger. Altinn har for eksempel forskjellige limits avhengig av hvilke API-er du bruker. Sjekk dokumentasjonen for hver tjeneste du integrerer mot.
Er det mulig å bruke Maskinporten fra mobil-apper?
Teknisk mulig, men ikke anbefalt av sikkerhetsmessige årsaker. Maskinporten er designet for server-til-server kommunikasjon hvor du kan beskytte den private nøkkelen ordentlig. For mobil-apper bør du heller ha et mellomliggende API som håndterer Maskinporten-integrasjonen.
Kan jeg dele Maskinporten-tokens mellom forskjellige prosesser?
Access tokens fra Maskinporten kan teknisk sett brukes av forskjellige prosesser, men vær forsiktig med caching og deling. Tokens har kort levetid (120 sekunder), så det må håndteres riktig. Jeg bruker gjerne Redis eller lignende for token-caching når jeg har flere prosesser som trenger samme tilgang.
Hva gjør jeg hvis Maskinporten er nede?
Maskinporten har generelt god oppetid, men jeg har opplevd kortere nedetider. Implementer alltid retry-logikk med exponential backoff. Hvis Maskinporten er nede over lengre tid, kan du følge status på Digitaliseringsdirektoratet sine kanaler. Men planlegg for at systemet ditt kan håndtere midlertidige autentiseringsfeil.