Vil du gerne høre mere?
En MitID-integration starter typisk som en konkret opgave: en kundevendt-løsning der skal kunne logge danske brugere ind. Men beslutningen om, hvor MitID-laget skal sidde i jeres arkitektur, lever videre længe efter selve integrationen er færdig.
Det er det lag, der bestemmer hvor frit I kan tilføje nye identity providers, hvor stærkt I står compliance-mæssigt, og hvor afhængige I er af én leverandørs roadmap når noget skal skifte.
For organisationer med flere identitetsstrømme - Entra til medarbejdere, MitID eller sociale logins til kunder, måske partner-SAML - bliver det reelle valg derfor hurtigt et ejerskabsvalg: hvem ejer det fælles identitetslag, og hvor sidder det?
Det er ofte vigtigere end produktet, der lægges ovenpå.
En MitID-login går altid gennem en certificeret MitID-broker (fx Signaturgruppen, Criipto eller Nets), der oversætter MitID-protokollen til de standarder, jeres applikationer kan tale: OpenID Connect eller SAML.
Den binding kommer I ikke uden om og oven på den har I derimod et valg; Skal hver applikation tale direkte med den certificerede broker, eller skal I sætte jeres eget identitetslag ind imellem?
Ofte er det fordelagtigt med en identitetsbroker, der samler MitID med jeres øvrige identity providers (Entra, sociale logins, partner-SAML), og som applikationerne så taler med i stedet.
Det er på dette område, at de tre arkitekturmønstre nedenfor adskiller sig.
Identitetslaget afgør tre ting, der har konsekvens langt ud over MitID-integrationen i sig selv.
Når en managed platform håndterer alle tre, accepterer I leverandørens svar på dem. Det er et valg, der er værd at tage bevidst.
MitID alene, MitID plus Entra ID for medarbejdere, MitID plus sociale logins, MitID plus partner-SAML - og hvor enkelt det er at tilføje en ny IdP senere, fx hvis EU's eIDAS-2 wallet bliver relevant.
Det har både teknisk konsekvens (latency, region, failover) og compliance-konsekvens (dokumentation af adgangskontrol, dataresidens, audittræk).
Et cloud-skift, en udfasning af en managed platform, eller et nyt sikkerhedskrav rammer ofte identitetslaget først.
Dette er den enkleste vej på kort sigt. Hver applikation integrerer direkte mod en certificeret MitID-broker, og der er ikke noget identitetslag imellem. Det fungerer godt, når MitID er den eneste eksterne loginmetode, og når antallet af integrerede applikationer er lille.
Det skalerer dårligt, så snart billedet bliver bredere. Hver applikation skal selv håndtere session, claims, MFA-regler og fejlflows, og logik bliver duplikeret. Skal I tilføje sociale logins, partner-SAML eller medarbejder-login senere, står hver applikation alene med integrationen. For mange organisationer er det her, behovet for et centralt identitetslag opstår.
Managed CIAM-platforme som Auth0/Okta, Ping Identity og Curity er ikke selv certificerede MitID-brokere. De forbinder til en MitID-broker via fx OIDC eller SAML - afhængigt af hvilken broker I vælger - og brokeren leverer så MitID-flowet ind i CIAM-laget. CIAM-platformen leverer det fælles flow ud til jeres applikationer, regler om MFA og claims, og I slipper for at drive identitetslaget selv.
Det fungerer bedst, hvis MitID er én af flere loginmetoder, og I ønsker managed drift uden at bygge identitetslaget selv. Trade-offen er per-bruger-prismodellen, der kan blive dyr ved skala, og at I bytter én leverandørbinding ud med to (CIAM broker). Validér også, at platformens connector til en certificeret MitID-broker er vedligeholdt og dokumenteret, ikke en mulig custom-integration.
Microsoft Azure AD B2C hører også til i denne kategori og har for mange danske organisationer været en velfungerende vej til MitID. Microsoft leverer ingen officiel MitID-understøttelse, men B2C's custom policies har givet plads til den orkestrering, integrationen kræver. Det billede ændrer sig nu: Microsoft udfaser B2C i 2030, og efterfølgeren Entra External ID har ikke samme custom policy-flade. MitID-tunge setups på Microsoft-stakken står derfor med en konkret migreringsbeslutning - vi har skrevet en separat gennemgang af, hvad den kræver (se relateret indhold).
Den tredje vej er at lægge MitID bag en identitetsbroker, I selv ejer. Dermed ejer I ikke kun jeres data, men også flows, claims og sessions - og I er ikke bundet af én cloud eller én platforms roadmap.
Det er den vej, der giver mest fleksibilitet og stærkest compliance-position - og som rummer voksende identitetsbehov uden at I skal skifte platform igen om to år. Den kræver til gengæld mest af jeres organisation, enten i form af driftskapacitet eller en partner, der leverer den. Vi har skrevet en bredere gennemgang af Keycloak som identitetsplatform: hvornår det giver mening, hvad det kræver, og hvilke konsumptionsmodeller der findes (se relateret indhold).
Det er ofte den rigtige vej i et enterprise-setup, og særligt klart, når en eller flere af følgende gælder:
MitID-login er en kritisk del af brugeroplevelsen, og I vil ikke acceptere, at en managed leverandørs roadmap bestemmer flowets fremtid.
I opererer i et reguleret miljø, hvor I skal kunne dokumentere ejerskab over identitetsdata og adgangskontrol - ikke kun stole på leverandørens dokumentation.
I har en multi-cloud- eller cloud-agnostisk strategi, hvor en cloud-bundet identitetsplatform bliver et lock-in-punkt.
I har komplekse login-flows, der ligger i grænselandet af eller udover, hvad managed CIAM komfortabelt understøtter.
I har behov for at konsolidere flere identity providers (MitID, Entra, sociale logins, partner-IdPs) bag ét konsistent lag, hvor I styrer logikken.
Løsning A og B har begge reelle styrker, særligt på time to market og når flowet er simpelt. Det bliver sværere, når kompleksiteten vokser - flere identity providers, særlige claims-regler eller sikkerhedskrav, der ligger uden for hvad platformen kan ud af boksen. Mange ender med at bygge et monster af workarounds rundt om identitetsplatformen for at få den til at gøre noget, den ikke er designet til.
Står I overfor at integrere MitID i et enterprise-setup, anbefaler vi typisk denne rækkefølge:
Er det infrastruktur, I helst ikke vil bruge tid på, eller en kapabilitet I aktivt vil eje? Svaret styrer det meste af det øvrige valg.
Hvilke identity providers bruger I i dag, og hvilke kommer til over de næste 3-5 år? MitID alene er ét billede; MitID som én af fem er et andet.
Hvilke krav stiller jeres sektor, og hvad er jeres cloud-strategi? Det afgør, om en managed platform overhovedet er på bordet.
Når retningen er klar (managed CIAM vs. selvkontrolleret broker), bliver produktvalget langt enklere.
Hos Immeo har vi designet identitetsarkitekturer med MitID-integration både på Microsoft-stakken, på Auth0 og på Keycloak. Står I med en MitID-integration, der skal designes - eller en eksisterende, der knirker - tager vi gerne en konkret arkitekturvurdering med jer.
Det er et afgrænset forløb, hvor I får en anbefaling at arbejde videre med, uanset om resultatet bliver Entra, Keycloak eller en hybrid.
