Hvilket sikkerhetsnivå krever Altinn-tjenesten, og hvorfor får jeg 403 på nivå 2?

Hva er sikkerhetsnivåene i Altinn?

Et mål på hvor sterkt kalleren beviste hvem den er, festet til økten eller tokenet ved autentisering. De svakeste metodene ligger nederst: en innlogging med brukernavn og passord gir tilgang til tjenester som krever nivå 1. Sterkere e-ID-er autentiserer på høyere nivåer, og et ID-porten-token noterer resultatet i acr-claimet sitt, med Level3 som dokumentert eksempel. Nivået er ikke en rettighet: det sier ingenting om hva kalleren får gjøre, bare hvor sikkert Altinn vet hvem som kaller.

Maskiner har også nivåer, og det er her modellen biter integratører. Autentisering med virksomhetssertifikat gir sikkerhetsnivå 3, og dokumentasjonen er uttrykkelig på at den bare gir det. Altinn-tokenet fra vekslingsendepunktet gjør verdien synlig: det dokumenterte organisasjonstokenet bærer et AuthenticationLevel-claim med verdien 3. Taket for et maskinkall er altså nivå 3, og ingen scope, delegering eller sertifikatstyrke hever det.

Nivå 4 finnes over dette, nådd med de sterkeste e-ID-ene. For det dokumenterte meldingstjenestetilfellet kan en tjeneste på nivå 4 bare leses gjennom ordinær innlogging via ID-porten, og maskinintegrasjon er ikke mulig der. Det ene faktumet avgjør et arkitekturspørsmål: enhver arbeidsflyt som berører en flate på nivå 4, trenger et menneskelig steg, og å late som noe annet gir et avslag ingen kodeendring kan fikse.

Hvordan angir tjenesten minstenivået, og hva skjer under det?

I Altinn 3 bor kravet i tjenestens autorisasjonspolicy. Avgjørelsen som returneres for en forespørsel, kan bære en forpliktelse hvis attributtkategori er urn:altinn:minimum-authenticationlevel, med en heltallsverdi; det dokumenterte eksempelet setter den til 2. Formen betyr mer enn tallet: minstenivået er en egenskap ved ressursens policy, valgt av tjenesteeieren, så to tjenester bak samme vert kan kreve ulike nivåer og besvare samme legitimasjon forskjellig.

Når legitimasjonen ligger under det angitte minstenivået, avvises forespørselen selv om rettighetskontrollen ville passert. Det er svaret på spørsmålet i sidens tittel: en 403 på nivå 2 er policyen som krever større sikkerhet om hvem som kaller, enn legitimasjonen din gir. Løsningen ligger aldri i forespørselens innhold og alltid på legitimasjonssiden, som er det som skiller denne feilen fra hver annen 403 i feilsøkingssiloen.

Hvordan avslaget kommer til syne, er mindre ryddig enn modellen. Integratører observerer at et for lavt nivå ikke alltid kommer som et merket avslag: det kan dukke opp som en generisk feilside, eller som en serverfeil som ikke nevner sikkerhetsnivåer. Ingenting på de offisielle sidene lover disse formene, så behandle dem som observasjoner og ikke kontrakt, og ta til deg feilsøkingsregelen de peker på: på en nivåstyrt flate er en uforklart avvisning et nivåproblem til legitimasjonens claims beviser noe annet.

Hvordan feilsøker jeg et nivåproblem og ikke et rettighetsproblem?

Skill de to portene først. En rettighetsfeil handler om hva kalleren får gjøre, og sporet går gjennom delegeringer, pakker og scopes; den klyngen eies av feilsøkingsveiledningen for systembrukere og feilsøkingsveiledningen for delegering. En nivåfeil handler om hvordan kalleren ble autentisert, og sporet er ett punkt langt: hvilket nivåclaim bærer legitimasjonen som faktisk legges fram.

For maskinkall løser det ene punktet nesten alltid saken. Dekod tokenet du faktisk sender, og se etter AuthenticationLevel-claimet: et rått Maskinporten-token har ikke noe, og løsningen er å sende det gjennom vekslingen først, som veiledningen om tokenveksling eier fra ende til ende. Er claimet på plass og tjenesten fortsatt avviser, ligger du enten under et høyere minstenivå eller på en flate på nivå 4, og løsningen er sterkere legitimasjon eller et menneskelig steg, ikke enda et forsøk.

Delen til Apier i denne disiplinen er det første oppslaget, ikke førflygingen. GET /api/v1/company/{org}/authority svarer på hvem som kan opptre for selskapet, fra Brønnøysund, før du ber noen om å godkjenne noe; selve nivåkravet, og kontrollene en innsending ville møtt, ligger hos Altinn og din egen klient. Handlingsendepunktet som før kjørte de kontrollene som prøveinnsending, ble satt på vent 21. oktober 2026 og svarer 410 CAPABILITY_WITHDRAWN.

Gjør det første kallet

Sandkassekallet svarer på hvem som overhodet kan opptre for et selskap, uten nøkkel. TypeScript-eksempelet er produksjonsutgaven av samme spørsmål, med én Apier-nøkkel: de registrerte signatarene for et selskap, slik at godkjenningen du ber om, er en godkjenneren kan gi.

# Nøkkelløs sandkasse: hvem som kan opptre for et selskap, fra registeret.
curl -s https://www.apier.no/api/v1/sandbox/public/company/999999999/authority

// Før kjeden: hvem som kan opptre for selskapet, fra registeret,
// med én Apier-nøkkel. Ingenting sendes inn.
// Bytt ut {org} med et ekte organisasjonsnummer; 999999999 finnes bare i sandkassen.
const res = await fetch("https://www.apier.no/api/v1/company/{org}/authority", {
  headers: { Authorization: `Bearer ${process.env.APIER_API_KEY}` },
});

if (!res.ok) {
  // Alle ikke-2xx-svar bruker den samme strukturerte konvolutten.
  const { error_code, explanation } = await res.json();
  throw new Error(`${error_code}: ${explanation.summary}`);
}

const { data, _meta } = await res.json();
// "sole" | "joint" | "by_role" | "prokura_only" | "no_authority" | "unknown"
console.log(data.classification, data.summary, _meta.data_source);

Ofte stilte spørsmål

Hvor kommer sikkerhetsnivået mitt egentlig fra?

Fra hvordan kallet ble autentisert, ikke fra hva det har lov til å gjøre. En innlogging med brukernavn og passord ligger på nivå 1, og sterkere e-ID-er autentiserer på høyere nivåer. På maskinsiden gir autentisering med virksomhetssertifikat nivå 3, og Altinn-tokenet fra vekslingsendepunktet bærer et AuthenticationLevel-claim, med 3 som dokumentert verdi for et organisasjonstoken. Nivået følger økten eller tokenet; rettigheter og delegeringer sjekkes for seg.

Delegeringen min er gyldig. Hvorfor avvises kallet likevel?

Fordi nivåkontrollen og rettighetskontrollen er to forskjellige porter, og å passere den ene sier ingenting om den andre. Den vanlige maskinformen er et rått Maskinporten-token sendt til en flate hvis policy krever et minstenivå: det rå tokenet bærer ikke noe AuthenticationLevel-claim i det hele tatt, så policyen har ingenting å godta. Veksles tokenet først, legges claimet til, og den samme delegeringen passerer.

Kan en maskin nå en tjeneste som krever nivå 4?

Ikke i det dokumenterte meldingstjenestetilfellet. Dokumentasjonen sier at meldingstjenester på sikkerhetsnivå 4 bare kan leses gjennom ordinær innlogging via ID-porten, og at maskinintegrasjon ikke er mulig der, siden sertifikatautentisering bare gir nivå 3. Når en flyt treffer en slik tjeneste, er den ærlige designen en overlevering: et menneske autentiserer seg med en e-ID på nivå 4 og utfører det ene steget.

Hvorfor får jeg noen ganger en generisk feilside eller 500 i stedet for et tydelig avslag?

Integratører observerer at et for lavt nivå ikke alltid dukker opp som et merket avslag: svaret kan komme som en generisk feilside eller en serverfeil som ikke nevner sikkerhetsnivåer. Ingenting av dette er dokumentert atferd å bygge på. Den praktiske regelen er å behandle en uforklart avvisning på en nivåstyrt flate som et nivåproblem først, og sjekke hva legitimasjonen bærer før du behandler den som et driftsavbrudd.

Hva svarer Apier på før jeg treffer nivåveggen?

Registerhalvdelen av kjeden: hvem som har signaturrett eller prokura for selskapet, fra Brønnøysund, med kilde og dato, slik at personen du ber om å godkjenne en systembruker eller et steg på nivå 4, er en med myndighet som dekker det. Apier kjører ingen førflygingskontroller for innsendingshandlinger; det endepunktet ble satt på vent 21. oktober 2026 og svarer 410 CAPABILITY_WITHDRAWN, og ingenting Apier gjør hever eller omgår et autentiseringsnivå.