Hopp til innholdet
ENStudio (åpnes i ny fane)
Meny

Guider · Data og tilgang

Enkel pålogging: én innlogging, og ett sted å ta den bort

Hvert internt verktøy med sitt eget passord er en liste over folk som noen må huske å oppdatere. Enkel pålogging erstatter alle de listene med den ene dere allerede holder ved like.

7 min lesingOppdatert 5. oktober 2026Softeria, Ålesund

Kortversjonen

  • Enkel pålogging betyr at verktøyet ikke har noe passord. Det spør firmakatalogen hvem personen er, og stoler på svaret.
  • Den egentlige gevinsten er ikke bekvemmelighet. Det er at én konto som slås av på ett sted, avslutter tilgangen overalt.
  • La gruppene dere allerede vedlikeholder avgjøre hvem som når hva, så det ikke finnes en ny liste over folk som må holdes i takt med den første.
  • Spør før dere kjøper: hvilken standard, om passordinnlogging kan slås av, hvor lenge en økt varer etter at kontoen er borte, og om enkel pålogging koster ekstra.

Tell de interne verktøyene i organisasjonen deres som har sitt eget innloggingsbilde: bookingsystemet, leverandørregisteret, skjemaet en avdeling bygde, rapportverktøyet noen kjøpte med kortet. Hvert av dem har sin egen liste over brukere og sine egne passord, og hver av de listene må oppdateres for hånd hver gang noen begynner, bytter rolle eller slutter.

De fleste av de listene er feil akkurat nå. Ikke grovt feil, bare litt: en innleid konsulent fra i fjor vår, en kollega som gikk over til en annen avdeling og beholdt det hun hadde. Enkel pålogging er måten å slutte å føre listene på i det hele tatt.

Hva enkel pålogging faktisk er

Med enkel pålogging ser verktøyet aldri et passord. Når noen åpner det, blir de sendt til firmaets identitetsleverandør — Microsoft Entra ID, Google, Okta eller lignende — som sjekker hvem de er på den måten firmaet har bestemt, og sender dem tilbake med en signert erklæring: dette er Kari, hun er med i disse gruppene. Verktøyet stoler på erklæringen og slipper henne inn.

To standarder gjør nesten hele denne jobben. OpenID Connect er den nyere og den de fleste moderne verktøy bruker; SAML er eldre og fortsatt vanlig i stor bedriftsprogramvare. Begge er greit. Det som betyr noe, er at det er en av dem, og ikke noe en leverandør har funnet på selv.

  • Det er ikke en passordbehandler. En passordbehandler husker mange passord for deg. Enkel pålogging betyr at det bare finnes ett, og at bare katalogen deres har det.
  • Det er ikke «samme passord overalt». Å synkronisere ett passord inn i ti systemer legger ti kopier av det på ti steder. Enkel pålogging legger det på ingen av dem.
  • Det er ikke en personlig «Logg på med Google». En privat Gmail-konto som logger på et jobbverktøy, er fortsatt en personlig konto. Det må være firmaets katalog, ellers kan ikke firmaet slå den av.

Hva separate passord koster

Argumentet for enkel pålogging blir som regel ført som bekvemmelighet — én innlogging i stedet for tolv — og bekvemmelighet er den svakeste delen av det. Kostnadene ved separate passord ligger andre steder.

  • De som slutter, beholder tilgangen. Når noen slutter, blir firmakontoen slått av. Det når ikke verktøyet med sin egen brukerliste, med mindre noen husker at verktøyet finnes og har rettigheter til å endre det.
  • Sikkerhetsreglene deres stopper ved døren. Tofaktorinnlogging, blokkerte land, bare administrerte enheter — uansett hva katalogen deres håndhever, hopper et verktøy med eget passord over alt sammen.
  • Passord blir gjenbrukt. Folk finner ikke på et nytt, sterkt passord til bookingsystemet for kantina. De bruker et de allerede har, som nå bare er så trygt som det minst forsiktige nettstedet de har brukt det på.
  • Ingen kan si hvem som har tilgang. Når en revisor eller en kunde spør hvem som kan nå et system, er svaret spredt over et dusin adminskjermbilder, og noen av dem tilhører folk som har sluttet.

Dagen noen slutter

Det er dette øyeblikket enkel pålogging egentlig er til for. Deaktiver én konto i katalogen, og neste gang den personen prøver å åpne et tilkoblet verktøy, sier identitetsleverandøren nei. Det finnes ingen liste å gå gjennom, så det finnes ingenting på den å glemme.

Det er verdt å være presis om hullene, for det finnes noen, og det er der kontrollene bør settes inn.

  • Økter som allerede er åpne. En som logget inn i morges, kan være innlogget til økten løper ut, også etter at kontoen er deaktivert. Finn ut hvor lenge det er i hvert verktøy — minutter og timer er greit, uker er det ikke.
  • Innlogginger som går utenom. Mange verktøy har en passordinnlogging ved siden av enkel pålogging, for den første administratoren eller av gammel vane. En konto som opprettes der, ligger utenfor katalogen deres og overlever alt det ovenfor.
  • Nøkler og tokener. Integrasjonsnøkler og personlige tilgangstokener blir ofte opprettet av en person og lever videre etter at personen har gått. De bør høre til en tjeneste, med en navngitt eier, ikke til den som tilfeldigvis satte dem opp.

Grupper, ikke lister

Enkel pålogging svarer på «hvem er dette». Neste spørsmål er «hva får de gjøre», og det fristende svaret er å gi hvert verktøy sin egen liste igjen: Kari er redaktør her, administrator der. Det bygger opp igjen problemet enkel pålogging nettopp fjernet.

Det bedre mønsteret er å la gruppene dere allerede vedlikeholder avgjøre. Økonomigruppen kan godkjenne fakturaer; lagergruppen kan registrere leveranser. Når Kari flytter fra økonomi til lageret, endrer noen gruppene hennes i katalogen — noe de uansett skulle gjøre — og hvert verktøy følger etter uten å bli rørt.

Grupper avgjør hvilke dører en person får åpne. De avgjør ikke hvilke poster som er deres når de først er inne: det er et eget spørsmål, som besvares ved dataene, og guiden om tilgang på radnivå tar for seg det.

Hva dere bør spørre om før et verktøy får brukere

Dette er spørsmålene som er verdt å stille om ethvert verktøy, kjøpt eller bygget, før noen får lov til å logge inn i det. Hvert av dem har et kort svar hvis leverandøren har tenkt gjennom det.

  • Hvilken standard? OpenID Connect eller SAML, og virker det med identitetsleverandøren dere faktisk bruker? «Vi støtter Microsoft» er ikke et svar før dere vet hvilken del av Microsoft.
  • Er det inkludert? Enkel pålogging er ofte forbeholdt den dyreste planen. Finn det ut før piloten, ikke ved fornyelsen, for det er den billige planen med separate passord folk i det stille kommer til å fortsette å bruke.
  • Kan passordinnlogging slås av? Hvis den ikke kan det, er enkel pålogging et alternativ, ikke en regel, og sidedøren står åpen.
  • Leses gruppene ved innlogging? Følger tilgangen gruppene i katalogen deres slik de er i dag, eller blir de kopiert én gang og aldri oppdatert?
  • Hvor lenge varer en økt etter at kontoen er borte? Det ærlige tallet, og om en administrator kan avslutte en økt før tiden.
  • Hvor blir innlogginger registrert? Identitetsleverandøren registrerer at noen logget inn. Verktøyet bør registrere hva de gjorde når de først var inne — og dere bør kunne lese det.

Slik fungerer det på vår plattform

Siden dere kanskje leser dette på nettstedet til et selskap som selger en plattform: det som bygges med Softeria, logger folk inn med kontoene de allerede har — Microsoft Entra ID, Google Cloud Identity eller en hvilken som helst OpenID Connect-leverandør som følger standarden, som Okta, Auth0 eller Keycloak. Vi utsteder ingen nye passord, gruppene dere allerede vedlikeholder avgjør hvem som når hva, og når noen forsvinner fra katalogen deres, opphører tilgangen.

Det som er verdt å ta med seg uansett hva dere bruker: et verktøy som fører sin egen liste over folk, er et verktøy noen kommer til å glemme den dagen det betyr noe. Gjør katalogen til den eneste listen, så blir det å avslutte en ansettelse ett steg i stedet for en jakt.

Vil dere ha versjonen som gjelder for dere?

Spør et menneske

En guide må generalisere. Fortell oss hva dere faktisk bygger, og hvem som skal holdes unna hva, så får dere et rett svar fra noen som jobber med plattformen — også når svaret er at vi ikke er det rette valget.