Hvorfor får jeg 401 eller 403 når jeg kaller Altinn API-er?
Når du integrerer et sluttbrukersystem mot Altinn API-er, kan du møte feilmeldingene 401 Unauthorized eller 403 Forbidden. De ligner, men betyr ikke det samme.
En enkel huskeregel er:
401 betyr: “Jeg vet ikke hvem du er.”
Token mangler, er ugyldig, er utløpt, eller kommer fra feil miljø.
403 betyr: “Jeg vet hvem du er, men du har ikke fullmakt til akkurat dette.”
Tokenet kan være gyldig, men systemet, klienten, brukeren, eller systembrukeren mangler nødvendig fullmakt, scope, token-type, delegering, eller rettighet til ressursen det kalles på.
Den vanligste feilen er å reagere på en 403 ved å hente ny token. Det kan hjelpe ved 401, men løser sjelden 403 alene.
Hvordan API-et bruker tokens til å gi eller nekte tilgang
Når en forespørsel kommer inn til et API, skjer det vanligvis to kontroller i rekkefølge.
Først sjekkes det hvem du er. API-et kontrollerer om tokenet finnes, er ekte, ikke er utløpt, og kommer fra en utsteder Altinn stoler på. Hvis dette feiler, får du normalt 401 Unauthorized.
Deretter sjekkes det om du får lov til å gjøre handlingen. API-et vurderer om tokenet har riktig scope, riktig type, og om brukeren, virksomheten, klienten, eller systembrukeren har fullmakt til ressursen eller handlingen. Hvis dette feiler, får du normalt 403 Forbidden.
Et token er digital legitimasjon. Den sendes med i API-kallet og forteller API-et hvem som kaller, hvor tokenet kommer fra, og hva tokenet kan brukes til.
Et token har kort levetid. Det er en sikkerhetsmekanisme. Hvis et token kommer på avveie, skal den raskt bli ubrukelig. Derfor må systemer hente nye tokens jevnlig.
Det er viktig å huske at et token ofte er et øyeblikksbilde. Hvis en fullmakt, delegering, eller scope nettopp er endret, kan gamle tokens mangle den nye fullmakten. Da må tokenet hentes på nytt.
Hvilke token-typer finnes?
| Token-type | Brukes typisk til | Vanlig feilkilde |
|---|---|---|
| Personlig token via ID-porten | Når en person handler som seg selv eller på vegne av en virksomhet | Brukes mot endepunkt som forventer virksomhet/system |
| Maskinporten-token | Maskin-til-maskin-integrasjoner for virksomheter | Mangler scope eller brukes direkte der API-et forventer Altinn-token |
| Virksomhetstoken / Altinn enterprise token | Når et Altinn API krever Altinn-utstedt virksomhetstoken | Maskinporten-token sendes direkte til feil endepunkt |
| Plattform-token | Interne Altinn-kall | Eksterne integrasjoner prøver å kalle interne endepunkter |
| Test-token | Lokal utvikling og test | Brukes utenfor miljøet den er ment for |
For sluttbrukersystemleverandører er særlig Maskinporten-token, virksomhetstoken, og eventuell systembruker/systemfullmakt relevante.
1. Sjekk miljø: TT02, test, og produksjon
Altinn har flere miljøer, og de må ikke blandes. En token fra ett miljø fungerer ikke nødvendigvis i et annet.
| Miljø | Hva det brukes til |
|---|---|
| AT-miljø | Tidlige testmiljøer for utviklingsteam - systemleverandører og tjenesteeiere bruker aldri disse miljøene (utenom eventuelle rettede forespørsler fra Digdir om bidrag i test) |
| TT02 | Offisielt testmiljø for integrasjoner mot Altinn |
| Produksjon | Ekte produksjonsmiljø for sluttbrukere og produksjonsintegrasjoner - skarpe data og integrasjoner mot tjenesteeiernes produksjonssystemer |
En vanlig feil er at tokenet er hentet fra produksjon, mens API-kallet går mot TT02, eller motsatt. En annen vanlig feil er at enkelte URL-er i konfigurasjonen peker mot riktig miljø, mens én URL fortsatt peker mot feil miljø.
Sjekk derfor alltid at tokenutsteder, klientoppsett, scope, API-endepunkt, og miljø hører sammen.
2. Feilsøking av 401 Unauthorized
401 betyr vanligvis at API-et ikke kan godkjenne hvem som sender kallet.
Typiske årsaker:
| Mulig årsak | Hva du bør sjekke |
|---|---|
| Token mangler | Sendes Authorization-header med? |
| Token er utløpt | Henter systemet ny token automatisk? |
| Feil miljø | Er token hentet fra samme miljø som API-et kalles mot? |
| Feil format | Mangler Bearer foran tokenet? |
| Token er kopiert feil | Er hele tokenet med? |
| Feil utsteder | Kommer tokenet fra en utsteder API-et stoler på? |
Ved 401 er første tiltak å hente et nytt token og kontrollere at den sendes riktig. Hvis feilen fortsetter, ligger problemet ofte i hvordan tokenet hentes eller sendes, ikke i selve fullmakten.
3. Feilsøking av 403 Forbidden
403 betyr vanligvis at API-et forstår hvem som kaller, men at kallet ikke har lov til å utføre akkurat denne handlingen.
Det finnes særlig tre hovedårsaker.
A. Tokenet mangler riktig scope
Scope er en merkelapp på tokenet som sier hva tokenet kan brukes til. Et token kan være gyldig, men likevel mangle scope for akkurat det API-et eller den handlingen som forsøkes utført.
Eksempler på scopes i Altinn-sammenheng kan være:
| Scope | Eksempel på betydning |
|---|---|
| altinn:authorization/authorize | Spørre om autorisasjonsavgjørelser |
| altinn:accessmanagement/read | Lese delegeringer |
| altinn:instances.write | Skrive til instans-API |
Scopes tildeles når virksomheten registreres som klient, ikke når kallet sendes. Hvis tokenet mangler nødvendig scope, må klientoppsettet endres eller tokenet hentes på nytt etter at scope er lagt til.
Eksempel på feilrespons:
{ "title": "Forbidden", "status": 403, "detail": "Insufficient scope", "instance": "<request-path>"}Dette betyr at tokenet ikke har tilstrekkelig scope for operasjonen.
B. Feil type token brukes
Noen endepunkter godtar bare bestemte token-typer. Et endepunkt som er ment for virksomheter kan avvise personlig token. Et endepunkt som krever virksomhetstoken kan avvise et rått Maskinporten-token. Interne plattformendepunkter er ikke ment for eksterne kall.
Feil token-type kan derfor gi 403 selv om tokenet ellers er gyldig.
C. Systembruker, virksomhet, eller klient mangler fullmakt
Dette er ofte den vanskeligste varianten, fordi alt teknisk kan se riktig ut. Tokenet kan være gyldig, scope kan finnes, og token-typen kan stemme, men kallet feiler fordi det mangler fullmakt til den konkrete virksomheten, ressursen, meldingen, dialogen, instansen, eller hendelsen.
For sluttbrukersystemleverandører kan dette for eksempel bety at systembrukeren mangler riktig fullmakt, at virksomheten ikke har gitt nødvendig fullmakt, at klientforholdet ikke er etablert, eller at det forsøkes å handle på vegne av feil virksomhet.
Ved slike feil hjelper det ikke å endre kode alene. fullmakten må korrigeres i Altinn.
4. Sjekkliste for 403 i Altinn API-er
Start med disse kontrollpunktene:
| Kontrollpunkt | Hva du bør avklare |
|---|---|
| Hvilket API feiler? | Profile API, Events API, Dialogporten, Authentication API, Apps API, eller annet |
| Hvilket endepunkt feiler? | Full URL og path |
| Hvilken metode brukes? | GET, POST, PUT, DELETE |
| Hvilket miljø brukes? | TT02, test/staging, produksjon |
| Hvem sender kallet? | Maskinporten-klient, systembruker, virksomhet, eller person |
| Hvilken token-type brukes? | Maskinporten-token, virksomhetstoken, personlig token, test-token |
| Hvilket scope kreves? | Sjekk API-dokumentasjonen |
| Finnes scopet i tokenet? | Ikke bare på klienten, men faktisk i tokenet |
| Er tokenet nytt? | Gamle/cachede tokens kan mangle ny fullmakt |
| Gjelder kallet riktig virksomhet? | Sjekk organisasjonsnummer og part |
| Finnes nødvendig delegering/systemfullmakt? | Sjekk fullmaktspakker, fullmakt, klientforhold, eller systembruker |
| Finnes traceId/correlationId? | Brukes ved videre feilsøking |
Se hvordan 401 og 403 oppstår i praksis
Hvis feilen er 401, er sannsynlig årsak at tokenet er utløpt, og at systemet ikke henter ny token riktig. Dette er normalt en autentiseringsfeil, ikke en rettighetsfeil.
Hvis et scope nylig er lagt til, kan systemet fortsatt bruke et gammelt eller cachet token. Hent en helt ny token og kontroller at scopet faktisk ligger i tokenet.
Da kan problemet være at virksomheten det handles på vegne av, ikke har gitt nødvendig fullmakt. For eksempel kan systemet forsøke å hente data for en virksomhet som ikke har delegert nødvendig fullmakt eller systemfullmakt.
TT02 og produksjon har egne oppsett, tokenutstedere, klienter, scopes, og fullmakter. At noe fungerer i test betyr ikke automatisk at samme fullmakt finnes i produksjon.
Vanlige misforståelser
Fullmakten kan være riktig, men tokenet kan være gammelt. Tokens er øyeblikksbilder av fullmaktene som gjaldt da tokenet ble hentet. Hent en ny token.
Ikke nødvendigvis. Personlige fullmakter, virksomhetsfullmakter, klientfullmakter, scopes, og systembrukerfullmakt er ulike ting. Én person eller klient sin fullmakt betyr ikke automatisk at en annen har samme fullmakt.
Ikke nødvendigvis. Test og produksjon er separate miljøer. fullmakter, konfigurasjon, klienter, delegeringer, og tokenutstedere må finnes i riktig miljø.
Ikke nødvendigvis. Mange 401- og 403-feil gir lite detaljer av sikkerhetshensyn. Det er derfor viktig å sende med tidspunkt, miljø, endepunkt, og sporings-ID ved behov for hjelp.
Ikke løst? Her får du støtte
Hvis dere fortsatt står fast etter å ha sjekket token, miljø, scope, token-type, og fullmakt, bør dere sende inn en mest mulig konkret henvendelse.
Send med:
| Informasjon | Eksempel |
|---|---|
| Tidspunkt | Kl. 14:32 norsk tid, 15. mai 2026 |
| Miljø | TT02 eller produksjon |
| API og endepunkt | Full URL, inkludert parametre |
| HTTP-metode | GET, POST, PUT, DELETE |
| Statuskode | 401 eller 403 |
| Feilmelding | For eksempel Insufficient scope |
| Token-type | Maskinporten-token, virksomhetstoken, personlig token |
| traceId/correlationId/request-id | ID fra responsen |
| Forventet resultat | Hva dere forsøkte å gjøre |
| Faktisk resultat | Hva som skjedde |