{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"cs/single-sign-on","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/cs/single-sign-on/","da":"https://cmaintz.github.io/tech-atlas/da/terms/cs/single-sign-on/"},"term":{"en":"Single sign-on (SSO)","da":"Single sign-on (SSO)"},"aka":{"en":["SSO"],"da":["SSO","fælles login"]},"domain":["cs"],"cluster":"identity","layer":"identity","status":"current","era":1988,"summary":{"en":"Logging in once to reach many separate applications, with a trusted identity provider vouching for the user to each.","da":"At logge ind én gang og få adgang til mange programmer, fordi en betroet identitetsudbyder går i god for brugeren."},"body":{"formal":{"en":"An arrangement in which a user proves who they are once to an identity provider, which then confirms that identity to each connected application, so the applications never see or store the user's password.","da":"En ordning, hvor en bruger beviser sin identitet én gang over for en identitetsudbyder, som derefter bekræfter identiteten over for hvert tilknyttet program, så programmerne aldrig ser eller gemmer brugerens adgangskode."},"plain":{"en":"Like a hotel key card from reception - you prove who you are once at the desk, and the gym, the pool and your room all trust the card.","da":"Som et hotelnøglekort fra receptionen - du beviser én gang ved skranken, hvem du er, og fitnessrummet, poolen og dit værelse stoler alle på kortet."},"inPractice":{"en":"Staff at a municipality sign in to Microsoft 365 in the morning and can then open the HR system, the staff website and the expenses app without typing another password.","da":"Medarbejderne i en kommune logger ind i Microsoft 365 om morgenen og kan derefter åbne HR-systemet, intranettet og appen til udlæg uden at indtaste flere adgangskoder."},"whyItMatters":{"en":"Fewer passwords means fewer to use again or steal, and closing one account locks every door at once - but that single login becomes very valuable and needs MFA.","da":"Færre adgangskoder betyder færre at genbruge eller stjæle, og lukkes én konto, låses alle døre på én gang - men det ene login bliver meget værdifuldt og kræver MFA."}},"deepDive":{"en":"Two technical families share the name. Enterprise or network SSO is dominated by Kerberos, which originated in MIT's Project Athena; version 5 is specified in RFC 4120. At logon the client obtains a ticket-granting ticket from the key distribution centre (the AS exchange), then presents it to request a service ticket for each service (the TGS exchange), so the password is used once and services only ever see tickets. Active Directory implements this, and browsers extend it to intranet web apps through SPNEGO and the HTTP Negotiate scheme (RFC 4559). Web SSO instead uses federation protocols: the application redirects the browser to an identity provider, which authenticates the user once and then returns a SAML assertion or an OpenID Connect ID token to each application in turn. On Entra-joined Windows devices, a Primary Refresh Token extends SSO to native and browser apps.\n\nThe mechanics explain most operational surprises. After the first login the IdP sets its own session cookie. When the user opens a second application, that application redirects to the IdP, the IdP sees its session and issues a new assertion without prompting (in OIDC the same silent path can be requested explicitly with prompt=none), and the application creates its own local session. There are therefore at least two session layers with independent lifetimes. Disabling a user at the IdP blocks new sign-ins immediately but does not end existing application sessions or revoke OAuth refresh tokens unless the applications support back-channel logout, continuous access evaluation or short sessions. Single logout in SAML and OIDC exists but is fragile across many applications.\n\nSecurity effects run both ways. SSO removes password prompts from dozens of applications, shrinks the phishing surface to one well-known login page, centralises MFA, conditional access and sign-in logging, and makes deprovisioning a single action. In return the IdP account becomes a master key, so it needs phishing-resistant MFA and careful monitoring. Benefits erode when applications keep local fallback logins, API tokens or break-glass passwords outside SSO; those should be inventoried and disabled or protected. Applications that need stronger assurance for specific actions can request step-up through SAML's requested authentication context or OIDC's acr_values and max_age.\n\nSeveral things are often mislabelled as SSO. Password synchronisation or LDAP bind against a central directory is \"same sign-on\": users type the same password everywhere and each application still sees it. Password vaulting or form-fill tools replay stored passwords. Federation is the cross-organisation case of SSO, where the IdP and the application belong to different trust domains and the trust is governed by metadata and agreements.","da":"To tekniske familier deler navnet. Virksomheds- eller netværks-SSO er domineret af Kerberos, der stammer fra MIT's Project Athena; version 5 er specificeret i RFC 4120. Ved logon får klienten en ticket-granting ticket fra key distribution centret (AS-udvekslingen) og fremviser den derefter for at få en servicebillet til hver tjeneste (TGS-udvekslingen), så adgangskoden bruges én gang, og tjenesterne kun ser billetter. Active Directory implementerer dette, og browsere udvider det til intranettets webapps via SPNEGO og HTTP Negotiate-mekanismen (RFC 4559). Web-SSO bruger i stedet føderationsprotokoller: Applikationen sender browseren videre til en identitetsudbyder, der autentificerer brugeren én gang og derefter returnerer en SAML-assertion eller et OpenID Connect ID-token til hver applikation i tur og orden. På Entra-joinede Windows-enheder udvider et Primary Refresh Token SSO til native apps og browserapps.\n\nMekanikken forklarer de fleste overraskelser i driften. Efter første login sætter IdP'en sin egen sessionscookie. Når brugeren åbner endnu en applikation, sender den browseren til IdP'en, IdP'en ser sin session og udsteder en ny assertion uden at spørge brugeren (i OIDC kan samme stille vej anmodes eksplicit med prompt=none), og applikationen opretter sin egen lokale session. Der er altså mindst to sessionslag med uafhængige levetider. At spærre en bruger hos IdP'en blokerer straks nye login, men afslutter ikke eksisterende applikationssessioner eller tilbagekalder OAuth-refresh-tokens, medmindre applikationerne understøtter back-channel-logud, continuous access evaluation eller korte sessioner. Fælles logud (single logout) findes i SAML og OIDC, men er skrøbeligt på tværs af mange applikationer.\n\nSikkerhedseffekten går begge veje. SSO fjerner adgangskodefelter fra snesevis af applikationer, reducerer phishingfladen til én velkendt loginside, samler MFA, betinget adgang og loginlogning ét sted og gør nedlukning af adgang til én handling. Til gengæld bliver kontoen hos IdP'en en hovednøgle, der kræver phishing-resistent MFA og omhyggelig overvågning. Fordelene udhules, når applikationer beholder lokale reservelogin, API-tokens eller nødadgangskoder uden for SSO; de skal registreres og slås fra eller beskyttes. Applikationer, der har brug for højere sikkerhed til bestemte handlinger, kan kræve step-up via SAML's requested authentication context eller OIDC's acr_values og max_age.\n\nFlere ting kaldes fejlagtigt SSO. Synkronisering af adgangskoder eller LDAP-bind mod et centralt directory er \"same sign-on\": Brugerne taster samme adgangskode overalt, og hver applikation ser den stadig. Værktøjer til password vaulting eller automatisk udfyldning af formularer afspiller gemte adgangskoder. Føderation er SSO på tværs af organisationer, hvor IdP'en og applikationen tilhører forskellige tillidsdomæner, og tilliden styres af metadata og aftaler."},"edges":[{"type":"requires","to":"cs/identity-provider","confidence":"high","strength":"normal"},{"type":"requires","to":"cs/session","confidence":"high","strength":"normal"},{"type":"implements","to":"cs/authentication","confidence":"high","strength":"normal"}],"depth":4,"sources":[{"title":"NIST SP 800-63C, Federation and Assertions","url":"https://pages.nist.gov/800-63-3/sp800-63c.html","tier":"standard","publisher":"NIST"}],"draft":true}