Egyszeri és külső szolgáltatós bejelentkezés

Célok

A lecke végére el tudod magyarázni, mit jelent az SSO és a külső szolgáltatóval történő bejelentkezés, miben különbözik a közös identitásszolgáltató a közös munkamenettől, és tudod, miért nem oldja meg egyik sem automatikusan a helyi jogosultságokat.

Miért nem akarunk mindenhol külön jelszót?

Ha egy egyetem több rendszert használ (kurzusrendszer, könyvtár, tanulmányi rendszer), és mindegyik saját jelszót kér, a hallgató sok jelszót kezel, ami gyenge jelszavakhoz és újrahasznált jelszavakhoz vezet. A rendszereknek mindegyiknek külön kellene védeniük a jelszavakat és kezelniük az elfelejtett jelszavakat. A megoldás a közös identitásszolgáltató: egy központi hely igazolja a felhasználót, és a többi rendszer erre támaszkodik. Az SSO (Single Sign-On, egyszeri bejelentkezés) azt a felhasználói élményt célozza, hogy az egyszer igazolt identitás több kapcsolódó alkalmazásba való belépéshez felhasználható.

Egyetemi portál, könyvtár és kurzusrendszer

A hallgató először a kurzusrendszerbe lépne be. A rendszer az egyetemi identitásszolgáltatóhoz irányítja, ahol igazolja magát. Az identitásszolgáltató eredményt ad vissza, a kurzusrendszer pedig saját munkamenetet hoz létre (7.2). Később a hallgató a könyvtári rendszerre lép. Az is ugyanahhoz az identitásszolgáltatóhoz fordul; ha ott a felhasználónak még érvényes bejelentkezési állapota van, új jelszóbeírás nélkül folytathatja.

sequenceDiagram
    participant H as Hallgató
    participant K as Kurzusalkalmazás
    participant I as Identitásszolgáltató
    participant L as Könyvtári alkalmazás
    H->>K: Belépés
    K->>I: Átirányítás hitelesítésre
    I-->>K: Hitelesítés eredménye
    H->>L: Könyvtár megnyitása
    L->>I: Hitelesítés kérése
    I-->>L: Eredmény, új jelszóbeírás nélkül

Az ábra fogalmi SSO-folyamat. Nem azt jelenti, hogy a két alkalmazás egymás cookie-ját olvassa. Mindkettő a közös identitásszolgáltatóval áll kapcsolatban, és külön, saját munkamenetet tarthat fenn. Ha a központi bejelentkezés lejárt vagy további ellenőrzés kell, a hallgatónak újra igazolnia kell magát.

Mit nyújt az SSO?

• Kevesebb jelszóbeírás, központi helyre szervezett identitás-ellenőrzés (jelszóházirend, többfaktoros hitelesítés egy helyen).
• A felhasználó egy helyen tudja kezelni a hozzáférését.
• Nem feltétlenül jelent egyetlen, minden alkalmazásban közös munkamenetet. A kurzusrendszer és a könyvtár saját hozzáférési szabályokat, munkamenet-időtartamot és kijelentkezési működést is használhat. Az identitásszolgáltató azt segít megállapítani, ki a felhasználó; a helyi rendszer dönti el, mit tehet.

Az SSO ára a függés: ha a központi identitásszolgáltató nem elérhető, az új bejelentkezések akadályozottak. A közös azonosítás biztonsági szempontból is jelentős, ezért a hitelesítés és a munkamenet védelmére külön figyelmet kell fordítani (8.4).

Külső szolgáltatóval való belépés

Egy webhely felkínálhatja, hogy a felhasználó egy másik szervezet identitásszolgáltatójánál jelentkezzen be. A felhasználó átirányítással jut a szolgáltatóhoz, ott igazolja magát, majd az alkalmazás ellenőrizhető identitásinformációt kap. A szabványos keret erre az OpenID Connect (7.5): a Kurzuspont az ID tokenből tudja meg a felhasználó azonosítóját (sub) és a kiállítót (iss). A helyi alkalmazás ezután saját felhasználói rekordot és munkamenetet kapcsol az identitáshoz.

Fontos, hogy a felhasználó külső azonosítója (kiállító + sub) lehet a kapcsolat kulcsa, nem például az e-mail-cím: az e-mail-cím megváltozhat, és nem minden szolgáltatónál ellenőrzött. A helyi rendszernek ezért saját felhasználói rekordot kell vezetnie, amelyhez a külső azonosító kapcsolódik.

A külső szolgáltató nem kap automatikusan jogot az alkalmazás adataira, és az alkalmazás sem ismeri meg a felhasználó külső jelszavát: szabványos átirányításos folyamatban a jelszó a szolgáltatónál marad. Ugyanakkor a felhasználónak tudnia kell, melyik szolgáltatóhoz irányítják, milyen adatokat kap az alkalmazás, és hogyan kapcsolódik a külső identitás a helyi fiókjához. Az adatkezelési kérdések külön mérlegelést igényelnek (9.6).

Bejelentkezés, kijelentkezés, hozzáférés

Az identitásszolgáltatónál történő sikeres belépés után a kurzusrendszernek a saját API-kéréseit is ellenőriznie kell (7.4): egy hallgató nem szerkeszthet tanári kurzust csak azért, mert a közös belépés sikerült. A kijelentkezés sem mindig egyetlen gombbal szüntet meg minden központi és helyi munkamenetet; a pontos élmény a rendszerek megállapodásától függ. A felületnek ezért világosan jeleznie kell, melyik alkalmazásból léptünk ki, és hogy a központi szolgáltatóból is kiléptünk-e.

flowchart TD
    K[Központi identitás: ki a felhasználó?] --> A1[Kurzusrendszer: saját munkamenet és jogosultságok]
    K --> A2[Könyvtár: saját munkamenet és jogosultságok]
    K --> A3[Tanulmányi rendszer: saját munkamenet és jogosultságok]

Végigvezetett példa: a Kurzuspont belépése

Lépés	Mi történik?
1.	A hallgató a „Belépés az egyetemi azonosítóval” gombra kattint.
2.	A Kurzuspont az egyetemi identitásszolgáltatóhoz irányít (OIDC, authorization code + PKCE).
3.	Az egyetemi szolgáltatónál a hallgató belép (jelszó + második tényező).
4.	A Kurzuspont ID tokent kap, ellenőrzi a kiállítót, a közönséget, a lejáratot és az aláírást.
5.	A Kurzuspont a (iss, sub) pár alapján megkeresi vagy létrehozza a helyi felhasználói rekordot.
6.	A Kurzuspont saját munkamenet-cookie-t ad, és innentől a saját jogosultsági szabályai szerint dönt (7.4).
7.	Később a könyvtárban a hallgató új jelszó nélkül jut be, mert az egyetemi szolgáltatónál még érvényes a bejelentkezése.

A lépések 4–6 ugyanazt a mintát követik, mint a nem külső bejelentkezés: azonosítás után a helyi rendszer szabályai érvényesek.

Gyakori tévhitek

Állítás	Pontosítás
„SSO esetén az alkalmazások egymás cookie-ját használják.”	Közös identitásszolgáltatóra támaszkodnak, saját munkamenetekkel.
„Egyszeri belépés = minden alkalmazásban ugyanaz a jogosultság.”	A helyi jogosultságok külön döntések.
„Külső belépéskor az alkalmazás megkapja a külső jelszót.”	Szabványos átirányításos folyamatban a jelszó a szolgáltatónál marad.
„Egy kijelentkezés biztosan minden munkamenetet megszüntet.”	A központi és a helyi munkamenetek élettartama eltérhet.
„Elég az e-mail-címet használni a külső fiók azonosítására.”	A kiállító és a sub a megbízható azonosító; az e-mail megváltozhat.

Röviden

• Az SSO egyszeri igazolással több alkalmazásba enged be; a háttérben közös identitásszolgáltató áll, az alkalmazásoknak saját munkamenetük van.
• Külső szolgáltatóval belépéskor jellemzően OpenID Connect adja az ellenőrzött identitást.
• A helyi jogosultság és munkamenet a helyi rendszer felelőssége marad.
• Az SSO előnye a kevesebb jelszó, ára a központi szolgáltatótól való függés.

Ellenőrző kérdések

1. Miért nem jelenti az SSO, hogy két alkalmazás megosztja a munkamenetét?
2. Miért jobb a külső azonosítót (iss + sub) használni az e-mail-cím helyett?
3. Mit nyerünk és mit kockáztatunk az SSO-val?
4. Miért nem elég a központi kijelentkezés a helyi munkamenet megszüntetéséhez?

Tanulási források

• OpenID Connect Core 1.0 — az ID token és az azonosítás; haladó olvasmány, angolul.
• HTTP authentication (MDN) — a HTTP hitelesítési alapjai.