Hopp til innhold

Hvilken legitimasjon trenger jeg: virksomhetssertifikat, virksomhetsbruker, systembruker eller Maskinporten-klient?

Av , gründer av Apier

Velg etter hvems myndighet kallet ditt bærer. En Maskinporten-klient registreres av din egen virksomhet og opptrer som deg. En systembruker delegeres av kunden din og lar deg opptre på kundens vegne i Altinn 3. En virksomhetsbruker er Altinn 2-æraens virksomhetsopprettede bruker, fortsatt i live i gamle integrasjoner, men på vei ut. Og virksomhetssertifikatet er ikke en tilgangslegitimasjon i det hele tatt: det er signeringsnøkkelen under en Maskinporten-klient, som i dag også kan være en direkte registrert JSON Web Key i stedet. De fleste integrasjoner trenger de to første og ingen av de to siste ved navn.

Et kart på to ganger to som parer situasjoner med legitimasjon. Å kalle et API din egen virksomhet har fått tilgang til, peker på en Maskinporten-klient, registrert av deg og som opptrer som deg. Å opptre for et kundeselskap i Altinn 3 peker på en systembruker, delegert av kunden. Å vedlikeholde en gammel Altinn 2-integrasjon peker på en virksomhetsbruker, en Altinn 2-konstruksjon på vei ut. Å signere assertions i bunnen peker på et virksomhetssertifikat eller en JWK, nøkkelen med to måter å holdes på. En merknad lyder: alle stier signerer med en nøkkel, og konstruksjonene skiller seg i hvems myndighet kallet bærer.Kaller et API din egen virksomhet har fått tilgang til?Maskinporten-klientregistrert av deg, opptrer som degOpptrer for et kundeselskap i Altinn 3?Systembrukerdelegert av kundenVedlikeholder en gammel Altinn 2-integrasjon?VirksomhetsbrukerAltinn 2-æra, på vei utSignerer assertions i bunnen?Virksomhetssertifikat eller JWKnøkkelen, to måter å holde denAlle stier signerer med en nøkkel. Konstruksjonene skiller seg i hvems myndighet kallet bærer.
To av de fire er gjeldende byggeklosser, én er arv, og én er ikke tilgangslegitimasjon i det hele tatt, men nøkkelen de andre signerer med. Spørsmålet som sorterer dem er aldri hvilken som er best, men hvems myndighet kallet må bære.

Hva lar hver legitimasjon deg faktisk gjøre?

En Maskinporten-klient er virksomhetens maskinidentitet. Du registrerer den selv, den autentiserer seg ved å signere en kortlevd JWT med en registrert nøkkel, og tokenene den mottar bærer scopene etatene har gitt til din virksomhet. Det den ikke kan, er å opptre for andre på egen hånd: en klient alene bekrefter din identitet, så data en etat knytter til en annen organisasjons samtykke forblir utenfor rekkevidde uansett hvor mange scopes du har.

Systembrukeren fyller nøyaktig det gapet. Den opprettes for en kundeorganisasjon og delegeres av noen med myndighet der, og tokenene klienten din så henter gjennom Maskinporten, identifiserer systembrukeren som opptrer for den kunden. Den kan ikke utvide dine egne scopes, og den finnes ikke før kunden gir den, som er et poeng: myndigheten på kallet er kundens, gitt med vilje, og kunden kan trekke den tilbake.

Virksomhetsbrukeren løste det samme problemet en plattformgenerasjon tidligere: en virksomhetsopprettet bruker for Altinn 2, som logger inn med brukernavn og passord paret med et virksomhetssertifikat. Den lever fortsatt i integrasjoner fra før Altinn 3, og det er den eneste situasjonen som krever den. Selve sertifikatet, til slutt, er ikke tilgangslegitimasjon, men den virksomhetsutstedte nøkkelen som signerer Maskinporten-assertions, og heller ikke den rollen er lenger eksklusiv, som de neste avsnittene dekker.

Beslutningstabellen: situasjonen du står i, legitimasjonen den krever, og begrensningen den bærer.
SituasjonLegitimasjonBegrensningen å huske
Kalle et API din egen virksomhet har fått tilgang tilMaskinporten-klient, registrert av deg.Opptrer som deg. Den kan ikke representere en kunde på egen hånd.
Opptre på vegne av kundeselskaper i Altinn 3Systembruker, delegert av hver kunde.Finnes ikke før kunden gir den, og kunden kan trekke den tilbake.
Vedlikeholde en integrasjon bygget på Altinn 2-API-etVirksomhetsbruker, med sertifikatstøttet innlogging.Kun arv. Planlegg migreringen; bygg ikke noe nytt på den.
Signere assertions en Maskinporten-klient senderNøkkel forankret i virksomhetssertifikat, eller en direkte registrert JWK.En nøkkel, ikke en tilgang. Å holde den autoriserer ingenting i seg selv.
Nå norske selskapsdata uten noe av det overEn Apier-nøkkel over de åpne registrene og regelboken.Bare signaturrett og frister; å opptre i Altinn krever fortsatt kundens egen delegering til systemet ditt.

Hva er gjeldende, og hva er på vei ut?

Den gjeldende modellen er Maskinporten-klienten pluss, når du opptrer for kunder, systembrukeren. Begge er dokumentert som den stående mekanismen: klienten autentiserer seg med en signert JWT og ingenting annet, og systembrukeren er Altinn 3-konstruksjonen for maskintilgang under en organisasjons myndighet. Ingenting ved noen av dem er midlertidig, og nye integrasjoner bør legge dem til grunn.

Virksomhetsbrukeren er den å planlegge seg bort fra. Den hører til Altinn 2, hvis nedstenging er varslet, og overgangen er datert der den berører rettigheter: Skatteetatens veiledning dokumenterer at roller og delegering av roller i Altinn 2 fjernes ved inngangen til 2027, med gamle tildelinger virksomme gjennom et overgangsvindu før det. En integrasjon som autentiserer seg som virksomhetsbruker i dag, virker fortsatt mot de gjenværende Altinn 2-flatene, og hver av de flatene har en migreringsdato et sted på seg.

Sertifikatets status er mer subtil: ikke avviklet, men ikke lenger eneste mulighet. Maskinporten dokumenterer to måter å holde en klients signeringsnøkkel på, forankret i et virksomhetssertifikat fra Buypass eller Commfides, eller registrert direkte som ditt eget nøkkelsett, som dokumentasjonen rammer inn som måten å unngå å spre sertifikater. Valget påvirker hvordan du lagrer og roterer nøkkelen, ikke hva klienten kan gjøre.

Hvordan henger delene sammen i en reell integrasjon?

De stables i stedet for å konkurrere. En leverandør som betjener regnskapskunder, ender med én Maskinporten-klient, forankret i én nøkkel, som henter token som opptrer gjennom én systembruker per kunde. Klienten er din, delegeringene er kundenes, og nøkkelen er det stille laget i bunnen. Det forvirrende spørsmålet om hvilken man trenger, løser seg som regel til alle de gjeldende, hver med sin egen jobb.

Mekanikken i hvert lag eies av egne sider: detaljene om sertifikater, assertions og tokenmellomlagring av autentiseringsveiledningen, og spørsmålet om hvilket token en gitt Altinn 3-flate vil ha, Maskinportens eget eller det vekslede Altinn-tokenet, av veiledningen om tokenveksling. Denne siden forblir kartet; de sidene er terrenget.

For de åpne registerdataene Apier svarer på, finnes ingen av stabelen. Hvem som kan signere for et selskap og hva det må sende inn innen når, kommer fra Brønnøysund og regelboken, så applikasjonen din autentiserer seg med én Bearer-nøkkel, og ingen Maskinporten-klient, nøkkel eller systembruker er involvert på noen side. Apier formidler ingen av de fire konstruksjonene for API-ene hos etatene som trenger dem; de er dine, og det er også beslutningen ingen mellommann kan ta: at hver kunde gir, og kan trekke tilbake, myndighet over egne forhold.

Gjør det første kallet

Den første forespørselen trenger ingen legitimasjon i det hele tatt og lister hva én Apier-nøkkel låser opp. Den andre leser et selskaps registrerte signaturrett fra Apier, uten at noen av de fire konstruksjonene over dukker opp noe sted i kallet.

# Nøkkelløst: hva én Apier-nøkkel låser opp, inkludert scopevokabularet.
curl -s https://www.apier.no/api/v1/capabilities
// Fra Apier: registrert signaturrett for et selskap, uten sertifikat,
// uten klientregistrering og uten offentlig legitimasjon i din stack.
// 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 } = await res.json();
// "sole" | "joint" | "by_role" | "prokura_only" | "no_authority"
// | "unknown", pluss innehaverne.
console.log(data.classification, data.signaturrett_holders);

Ofte stilte spørsmål

Hva er forskjellen på en Maskinporten-klient og en systembruker?
Hvems myndighet kallet bærer. En Maskinporten-klient registreres av din egen virksomhet, og tokenene den henter bekrefter din identitet og dine tildelte scopes. En systembruker opprettes for en kundeorganisasjon og delegeres av den kunden, så kall gjort under den opptrer på kundens vegne. En integrasjon som betjener mange kunder, holder typisk én klient og opptrer gjennom én systembruker per kunde.
Er en virksomhetsbruker det samme som en systembruker?
Nei. En virksomhetsbruker er en Altinn 2-konstruksjon: en virksomhetsopprettet bruker som autentiserer seg med brukernavn og passord sammen med et virksomhetssertifikat mot Altinn 2-API-et. Systembrukeren er Altinn 3-mekanismen for maskintilgang under en organisasjons myndighet, med token hentet gjennom Maskinporten. Nye integrasjoner bør ikke bygges på virksomhetsbruker.
Trenger jeg fortsatt virksomhetssertifikat for Maskinporten?
Ikke nødvendigvis. Maskinporten dokumenterer to måter å holde signeringsnøkkelen på: forankret i et virksomhetssertifikat, eller registrert direkte som ditt eget nøkkelsett, som dokumentasjonen beskriver som måten å unngå å spre sertifikater. Uansett autentiserer klienten seg med en signert JWT; noen client secret-variant finnes ikke.
Hvilken av disse er på vei ut?
Virksomhetsbrukeren, sammen med plattformen den hører til. Nedstengingen av Altinn 2 er varslet, og Skatteetatens veiledning dokumenterer at roller og delegering av roller i Altinn 2 fjernes ved inngangen til 2027, etter et overgangsvindu. Maskinporten-klienten, systembrukeren og nøkkelen under dem er den gjeldende modellen.
Hvor står Apier i dette bildet?
Utenfor alle fire konstruksjonene. Apier holder ingen Maskinporten-klient, nøkler eller systembruker på dine vegne og formidler ingen av de flytene; de Altinn-baserte endepunktene Apier tidligere tilbød ble trukket tilbake 21. oktober 2026 og svarer 410 CAPABILITY_WITHDRAWN. Det Apier svarer på, kommer fra åpne registre og regelboken: hvem som kan signere for et selskap, hva det må sende inn og innen når, bak én API-nøkkel, med kilde og dato på hver respons.