Altinn vs Maskinporten: which does what
Maskinporten answers WHICH organization's software is calling — it issues short-lived OAuth2 tokens that authenticate the calling organization. Altinn 3 System Users answer ON WHOSE BEHALF that software may act — a delegation model where a target company grants rights to a registered non-human actor. Delegated actions need both: a Maskinporten token to authenticate, and an Altinn delegation to authorize.
Jurisdiction: Norway · Verified against Digitaliseringsdirektoratet / Altinn as of 2026-05-19
Two different questions
Maskinporten is authentication infrastructure: an OAuth2 layer where a client signs a JWS assertion with its organization certificate and receives a scope-bound access token identifying the integrating organization. Altinn is the government's digital services platform where actions actually happen — and its System User model is authorization infrastructure: an explicit, revocable grant from the target company to the integrating party. Authenticating successfully and being authorized to act are separate questions with separate failure modes.
How they compose
Altinn 3 is API-first and built on the same Maskinporten OAuth2 layer as the rest of Norwegian government infrastructure. A delegated Altinn call therefore carries a Maskinporten token (proving which organization calls) while Altinn checks the System User delegation (proving the target company allowed it). The three-leg setup interlocks them: a Maskinporten client, Samarbeidsportalen onboarding, and the Altinn System Register registration plus per-target delegation.
The classic pitfall
A System User that exists but has no rights granted authenticates successfully — the Maskinporten leg is fine — yet every action fails, because the Altinn delegation leg is missing. When debugging, always separate 'is the token valid?' (Maskinporten) from 'does the delegation grant this right for this target company?' (Altinn).
Altinn 2 vs Altinn 3
Altinn 3 replaced Altinn 2, which was deprecated on 19 June 2026. Identifiers and resource URIs differ — an Altinn 2 service code or role code cannot be reused against Altinn 3 without translation, and delegation moved from organization roles plus Altinn-internal rights to the System User model.
Use cases
- Decide whether a failing government call is an authentication problem (Maskinporten) or an authorization problem (Altinn delegation)
- Plan the credential and delegation setup for a new agent integration
- Translate an Altinn 2 integration's assumptions to the Altinn 3 model
Requirements
- For authentication: a Maskinporten client bound to a virksomhetssertifikat, onboarded in Samarbeidsportalen
- For authorization: an Altinn System Register entry plus a per-target delegation granted by each target company
Authentication
Method: api_key · Scopes: read:altinn
Via Apier both layers are held server-side; the agent checks the combined effective state through the permissions and acting-capacity endpoints instead of juggling the two credentials itself.
Common errors
MASKINPORTEN_AUTH_FAILED
The authentication leg failed — Maskinporten rejected the token exchange.
Fix: This is server-side credential/config drift the API client cannot repair — report it with the X-Correlation-ID from the response headers so the operator can correct the configuration; it persists until fixed there.
AUTH_NO_DELEGATION
The authorization leg failed — the target company has not delegated access.
Fix: The target company must add the System User and grant rights in its own Altinn portal (handover actor: altinn_user).
Related topics
Related APIs
Capability ids — resolve each against the machine-readable manifest at /api/v1/capabilities for the endpoint, auth mode, and tier.
- auth.permissions
- auth.acting_capacity
- auth.delegate
Related MCP tools
Registered tools on the Apier MCP server.
- check_authorization
- list_acting_capacity
- get_altinn_migration_guidance