Single sign-on (SSO)

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.

Mekanikken 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.

Sikkerhedseffekten 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.

Flere 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.