← 7. Systems thinking – A nagy kép

7.5 Autentikáció és authorizáció – a különbség és a practice

Áttekintő

Két fogalom, amit sokan felcserélnek – és ha felcseréled, komoly security rés lehet belőle. Az autentikáció azt jelenti: „ki vagy te?" Az authorizáció azt jelenti: „mit tehetsz meg?"

Ez első hallásra triviálisnak tűnik, de a fejlesztési hibák jó része pontosan abból fakad, hogy a kettőt valaki összekeveri. Például egy rendszer megnézi, hogy be vagy-e jelentkezve (autentikáció), de nem ellenőrzi, hogy jogod van-e az adott erőforráshoz (authorizáció) – és ezzel az egyik felhasználó megnyithatja a másik adatait.

Ebben az alfejezetben megérted a különbséget, megismered a leggyakoribb auth megközelítéseket (session, token, JWT, OAuth2), és megérted, hogyan működik a szerepkör alapú jogosultságkezelés. Nem kriptográfia-kurzus ez – a lényeg a gondolkodásmód.

---

Részletes leírás

Autentikáció vs. authorizáció – a két fogalom

Autentikáció (Authentication, röviden: authn):

Ki vagy te? Bizonyítsd be.

Ez a bejelentkezés folyamata. A rendszer ellenőrzi, hogy a megadott azonosító és hitelesítő adat (jelszó, token, ujjlenyomat stb.) egyezik-e azzal, ami nála van.

Authorizáció (Authorization, röviden: authz):

Rendben, tudom ki vagy – de mit tehetsz meg?

Ez a jogosultságellenőrzés. A rendszer megnézi, hogy az azonosított felhasználónak van-e joga az adott műveletre vagy erőforráshoz.

A két folyamat sorrendje mindig ugyanaz:

1. Autentikáció → „Igen, te tényleg Kovács Péter vagy."
2. Authorizáció → „De Kovács Péternek nincs admin joga, ezt az oldalt nem láthatja."

Authorizáció autentikáció nélkül értelmetlen – ha nem tudod, ki a felhasználó, azt sem tudod, milyen jogai vannak.

---

Session alapú autentikáció – a klasszikus módszer

Ez a régebbi, de ma is széles körben használt megközelítés, különösen hagyományos, szerver által renderelt webalkalmazásokban.

Folyamata:

1. Felhasználó bejelentkezik (email + jelszó)
2. Szerver ellenőrzi a hitelesítő adatokat
3. Szerver létrehoz egy session-t (egy véletlenszerű azonosítót, pl. abc123xyz)
4. Ezt az azonosítót tárolja a szerveren (memóriában vagy adatbázisban)
5. Elküldi a böngészőnek egy süti (cookie) formájában
6. Minden további kérésnél a böngésző automatikusan visszaküldi a sütit
7. Szerver megkeresi a session-t, és azonosítja a felhasználót

Böngésző                          Szerver
   │── POST /login ──────────────►│
   │   {email, jelszó}            │ Ellenőriz, session létrehoz
   │◄── Set-Cookie: session=abc123│
   │                              │
   │── GET /profil ──────────────►│
   │   Cookie: session=abc123     │ Session-t megkeresi → azonosít
   │◄── 200 OK: profiladatok ─────│

Előnye: egyszerű, jól bevált, a szerver bármikor érvénytelenítheti a session-t (pl. kijelentkezésnél).

Hátránya: a session-t a szerveren kell tárolni. Ha több szerverpéldányod van (load balancer mögött), szinkronizálni kell a session-t köztük – különben a felhasználó minden második kérésnél „kijelentkezik" (ahogy a 7.4 alfejezetben is láttuk).

---

Token alapú autentikáció – a modern megközelítés

A token alapú auth esetén a szerver nem tárol semmit a bejelentkezési állapotról. Ehelyett a kliens kap egy tokent, és minden kérésnél elküldi azt.

Folyamata:

1. Felhasználó bejelentkezik
2. Szerver ellenőriz, majd kiad egy tokent (egy hosszú, aláírt sztringet)
3. A kliens eltárolja a tokent (localStorage, sessionStorage, vagy biztonságosabb: HttpOnly cookie)
4. Minden kérésnél elküldi az Authorization fejlécben
5. Szerver ellenőrzi a tokent – ha érvényes, azonosít

GET /api/profil
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Előnye: a szerver nem tárol állapotot (stateless), könnyen skálázható több szerverpéldányra.

Hátránya: a tokent nehezebb érvényteleníteni lejárat előtt (pl. kijelentkezésnél). Ezért van hozzájuk refresh token mechanizmus.

---

JWT – mi ez és miért látod mindenütt

A JWT (JSON Web Token) a legelterjedtebb token formátum. Nem kriptográfiai mélységek kellenek hozzá – elég érteni, hogy mi van benne és hogyan működik.

Felépítése három részből áll, pontokkal elválasztva:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjEyMywicm9sZSI6ImFkbWluIiwiZXhwIjoxNzE0NTAwMDAwfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
         HEADER (Base64)                              PAYLOAD (Base64)                                    SIGNATURE

• Header: milyen algoritmussal írták alá (pl. HS256)
• Payload: az adatok – ki a felhasználó, mikor jár le, esetleg milyen szerepköre van
• Signature: az első két rész aláírása egy titkos kulccsal – ez garantálja, hogy senki nem módosította

Kritikus pont: a payload nem titkosított – Base64 kódolt, de bárki dekódolhatja és elolvashatja. Soha ne tegyél JWT-be érzékeny adatot (jelszót, bankkártyaszámot stb.). Az aláírás csak azt garantálja, hogy nem módosították – de az adatok láthatóak.

Dekódold és nézd meg magad: a jwt.io oldalon bármilyen JWT tartalmát megnézheted.

Lejárat: a JWT-knek mindig legyen lejárati ideje (exp mező). Rövid élettartamú access token (pl. 15 perc) + hosszabb élettartamú refresh token – ez a leggyakoribb minta.

---

OAuth2 és „Sign in with Google" – hogyan működik valójában

Az OAuth2 egy szabvány, ami lehetővé teszi, hogy egy alkalmazás korlátozott hozzáférést kérjen egy másik rendszerhez a felhasználó nevében – anélkül, hogy a felhasználó jelszavát megkapná.

A „Sign in with Google" ennek egy tipikus felhasználása.

Mit lát a felhasználó:

1. Rákattint a „Bejelentkezés Google-lel" gombra
2. Google bejelentkezési oldal jelenik meg
3. Engedélyezi az alkalmazásnak a hozzáférést
4. Visszakerül az alkalmazásba, és be van jelentkezve

Mi történik valójában a háttérben:

1. Az alkalmazásod átirányítja a felhasználót a Google-höz
   (URL-ben megadja: ki az alkalmazás, mit kér hozzáférni, hova jöjjön vissza)

2. Felhasználó Google-nél hitelesíti magát

3. Google visszairányítja az alkalmazáshoz egy rövid életű kóddal (authorization code)

4. Az alkalmazás szervere elküldi ezt a kódot a Google-nek (a titkos kulccsal együtt)

5. Google visszaad egy access tokent (és esetleg id_tokent a felhasználói adatokkal)

6. Az alkalmazás a token alapján azonosítja a felhasználót, és belépve kezeli

Miért jobb ez, mint a jelszó megkérése?

• A te alkalmazásod soha nem látja a Google-jelszót
• Ha az alkalmazásod adatai kiszivárognak, a Google-fiók biztonságban marad
• A felhasználó bármikor visszavonhatja a hozzáférést a Google beállításainál

Mikor éri meg OAuth2-t implementálni?

• Ha „Sign in with X" gombot akarsz (Google, GitHub, Facebook)
• Ha a te API-dhoz harmadik fél alkalmazások is hozzáférhetnek

Juniorként sokszor nem te implementálod az OAuth2 folyamatot nulláról – hanem egy könyvtárat (pl. Passport.js, python-social-auth, Laravel Socialite) használsz. De érteni kell, mi folyik a háttérben, különben nem tudod, mikor hibázik.

---

Role-based access control (RBAC) – ki mit láthat

Az RBAC (Szerepkör alapú hozzáférés-vezérlés) a leggyakoribb authorizációs minta webapplikációkban.

Alapelve: a felhasználókhoz szerepköröket (role-okat) rendelünk, a szerepkörökhöz pedig jogosultságokat (permission-öket).

Felhasználó → Szerepkör → Jogosultságok
   Kovács Péter → admin   → mindent olvashat, módosíthat, törölhet
   Kiss Anna    → editor  → cikkeket olvashat és módosíthat, de nem törölhet
   Nagy Béla    → viewer  → csak olvashat

Implementáció szempontból ez tipikusan így néz ki:

# Példa: Python / FastAPI stílusban

def get_current_user(token: str):
    # token ellenőrzés, user visszaadása
    ...

def require_role(required_role: str):
    def decorator(user = Depends(get_current_user)):
        if user.role != required_role:
            raise HTTPException(status_code=403, detail="Nincs jogosultságod")
        return user
    return decorator

@app.delete("/users/{user_id}")
def delete_user(user_id: int, user = Depends(require_role("admin"))):
    # Csak admin érheti el
    ...

// Express / Node.js stílusban

function requireRole(role) {
    return (req, res, next) => {
        if (!req.user || req.user.role !== role) {
            return res.status(403).json({ error: 'Nincs jogosultságod' });
        }
        next();
    };
}

app.delete('/users/:id', authenticate, requireRole('admin'), deleteUserHandler);

// Laravel stílusban
Route::delete('/users/{id}', [UserController::class, 'destroy'])
    ->middleware(['auth', 'role:admin']);

Fontos részlet: a 403 (Forbidden) és 401 (Unauthorized) státuszkódok különbsége:

• 401 Unauthorized: nem vagy bejelentkezve (nincs autentikáció)
• 403 Forbidden: be vagy jelentkezve, de nincs jogod (autentikáció OK, authorizáció FAIL)

Sokan felcserélik ezt a kettőt a kódban – a megfelelő státuszkód megadása mind a kliensfejlesztőnek, mind a security auditornak sokat segít.

---

Életszerű példák

1. példa: Autentikációs vs. authorizációs bug élesben

Egy csapat API-t fejleszt. A /api/documents/{id} endpoint visszaadja a dokumentum tartalmát.

A hibás implementáció:

@app.get("/api/documents/{doc_id}")
def get_document(doc_id: int, user = Depends(get_current_user)):
    # Ellenőrzi, hogy be van-e jelentkezve (autentikáció ✅)
    document = db.get_document(doc_id)
    return document  # De nem ellenőrzi, hogy ez a user dokumentuma-e! (authorizáció ❌)

Mi a probléma? Bármelyik bejelentkezett felhasználó megnyithatja bármelyik másik felhasználó dokumentumát, ha ismeri az ID-t (pl. 1, 2, 3... – sokszor szekvenciálisak).

A helyes verzió:

@app.get("/api/documents/{doc_id}")
def get_document(doc_id: int, user = Depends(get_current_user)):
    document = db.get_document(doc_id)
    if document.owner_id != user.id:  # Authorizáció ellenőrzése ✅
        raise HTTPException(status_code=403)
    return document

Ez az egyik leggyakoribb real-world biztonsági hiba: az autentikáció megvan, de az authorizáció hiányzik.

---

2. példa: JWT lejárat és a kijelentkezés paradoxona

Egy fejlesztő stateless JWT-t implementál. Minden kérésre a kliens elküldi a tokent, a szerver ellenőrzi az aláírást és a lejáratot. Rendben van.

De mi történik, ha a felhasználó kijelentkezik?

A tévhit: „törlöm a tokent a kliens oldalon (localStorage) → kijelentkezett."

A valóság: ha valaki elmentette a tokent (pl. egy XSS-sérülékenységen keresztül), az még lejáratig érvényes. A szerver stateless, nem tudja, hogy a token „érvénytelen" – csak az aláírást és az expiry-t ellenőrzi.

Megoldások:

1. Rövid lejárat (pl. 15 perc) – kevesebbet kockáztatsz
2. Token blacklist – a szerver tárolja az érvénytelenített tokeneket (de ekkor már nem teljesen stateless)
3. Refresh token rotáció – minden refresh token egyszer használható, utána érvénytelen

Ebből is látszik: a „stateless JWT mindent megold" egy leegyszerűsítés. A valóságban trade-offok vannak, és a biztonsági igényektől függ, melyik megközelítést választod.

---

3. példa: „Sign in with Google" hibakereső szituáció

Fejlesztés közben implementálsz Google OAuth2-t. Helyi fejlesztésen működik, production-ban nem.

Tipikus okok:

• A Google Developer Console-ban a Authorized redirect URI csak a helyi URL-t tartalmazza, a production URL-t nem adtad hozzá
• CLIENT_SECRET nincs beállítva environment változóként production-ban
• A callback URL-ben HTTP van HTTPS helyett (Google csak HTTPS-t enged éles alkalmazásnál)

Tanulság: OAuth2 flow számos konfigurációs részlettől függ. Ha megy lokálisan de production-ban nem, mindig ellenőrizd a OAuth provider beállításait (allowed redirect URIs, environment-specifikus értékek).

---

4. példa: Role check a megfelelő helyen

Egy junior fejlesztő admin oldalt épít. Az admin route frontend oldalon el van rejtve, a menüből nem látszik – csak adminoknak.

A hibás gondolkodás: „a menüből nem látszik, tehát nem érhető el."

A valóság: bárki beírhatja a böngészőbe az URL-t (/admin), vagy közvetlenül hívhatja az API-t. A frontend-oldali elrejtés csak UX – soha nem security.

Az authorizációt mindig a backenden kell ellenőrizni, minden egyes kérésnél, minden egyes végponton. A frontend-oldali role-check kizárólag a felhasználói élmény javítása (ne lássanak olyat, ami úgysem működik nekik) – nem helyettesítheti a szerver oldali ellenőrzést.

---

Tesztfeladatok

1. Autentikáció vagy authorizáció?

Döntsd el, melyik fogalom írja le az adott szituációt:

a) A felhasználó megadja az email-jelszó párost, a rendszer ellenőrzi, hogy egyeznek-e a tároltakkal.
b) A rendszer megnézi, hogy a bejelentkezett felhasználónak van-e admin szerepköre, mielőtt mutatja a törlés gombot.
c) A JWT token aláírása érvényes, és a user_id mező értéke 42.
d) A 403 Forbidden válasz azt jelzi, hogy a felhasználó nem törölheti a másik felhasználó bejegyzését.
e) A kérés fejlécéből kivett Bearer token lejárt – a szerver visszautasítja.

---

2. Igaz vagy hamis?

a) A JWT payload Base64 kódolással titkosított, ezért biztonságos érzékeny adatot beletenni.
b) A session alapú autentikáció esetén a szerver tárolja a bejelentkezési állapotot.
c) A 401 és 403 státuszkód ugyanazt jelenti: hozzáférés megtagadva.
d) Az OAuth2 „Sign in with Google" esetén a te alkalmazásod megkapja a felhasználó Google-jelszavát.
e) Ha a frontend elrejt egy menüpontot a nem-admin felhasználóktól, az elegendő biztonsági intézkedés.

---

3. Melyik fogalom melyik definícióhoz illik?

---

4. Szituáció-diagnosztika

Egy webalkalmazásban a /api/orders/{id} endpoint visszaadja a rendelés részleteit. Béla, egy bejelentkezett felhasználó, megpróbálja megnyitni egy másik felhasználó rendelését – és sikerül neki.

a) Ez autentikációs vagy authorizációs hiba?
b) Milyen HTTP státuszkódot kellett volna visszaadni?
c) Mire kell figyelni a javítás során?

---

5. JWT értelmezése

Adott ez a dekódolt JWT payload:

{
  "user_id": 99,
  "email": "kovacs@pelda.hu",
  "role": "editor",
  "exp": 1714500000
}

a) Mit jelent az exp mező?
b) Biztonságos-e az email-t tárolni a JWT payload-ban? Indokold.
c) Ha ez a felhasználó megpróbál egy admin-only végpontot elérni, mi történjen?

---

6. Session vs. token

Melyik megközelítés melyik szituációhoz illene jobban, és miért? (Nincs egyetlen helyes válasz – az indoklás számít)

---

7. OAuth2 folyamat sorrendbe állítása

Az alábbi lépések összekeveredtek. Rendezd sorba a „Sign in with Google" folyamatot:

• A) A szerver elküldi az authorization code-ot a Google-nek, és kap egy access tokent
• B) A Google visszairányítja a felhasználót az alkalmazáshoz egy authorization code-dal
• C) Az alkalmazás a token alapján azonosítja a felhasználót, és belépve kezeli
• D) A felhasználó rákattint a „Bejelentkezés Google-lel" gombra
• E) Az alkalmazás átirányítja a felhasználót a Google autentikációs oldalára
• F) A felhasználó bejelentkezik a Google-fiókjával, és engedélyezi az alkalmazást

---

8. Státuszkód azonosítás

Melyik HTTP státuszkódot kell visszaadni az alábbi szituációkban?

a) A kérésben nincs Authorization fejléc – a felhasználó nincs bejelentkezve.
b) A bejelentkezett felhasználónak nincs admin jogosultsága az endpoint eléréséhez.
c) A token formátuma érvénytelen (nem JWT struktúra).
d) A felhasználó sikeresen törölte a saját bejegyzését.

Lehetséges válaszok: 200, 204, 400, 401, 403, 404

---

Tesztfeladat-megoldások

1.
a) Autentikáció – ki a felhasználó, bizonyítja be
b) Authorizáció – jogosultság ellenőrzése azonosítás után
c) Autentikáció – a token ellenőrzése és a user azonosítása
d) Authorizáció – azonosítva van, de nincs joga
e) Autentikáció – érvénytelen/lejárt token → azonosítás sikertelen

2.
a) Hamis – a payload Base64 kódolt, de nem titkosított; bárki dekódolhatja
b) Igaz – a szerver tárolja a session-t és ehhez keresi a felhasználót
c) Hamis – 401: nincs autentikálva; 403: autentikált, de nincs joga; nem ugyanaz
d) Hamis – OAuth2-nél az alkalmazás soha nem látja a Google-jelszót
e) Hamis – a frontend-oldali elrejtés csak UX, az authorizációt mindig backenden kell ellenőrizni

3. A-2, B-1, C-3, D-4, E-5

4.
a) Authorizációs hiba – a felhasználó be van jelentkezve (autentikáció OK), de más rendelését is el tudja érni (authorizáció hiányzik)
b) 403 Forbidden – autentikált, de nincs joga
c) Ellenőrizni kell, hogy a rendelés user_id-ja megegyezik-e a bejelentkezett felhasználó ID-jával, mielőtt visszaadod az adatot

5.
a) Az exp (expiration) a lejárati időt jelöli – Unix timestamp formátumban
b) Igen, elfogadható – az email nem különösebben érzékeny és nem titkos adat; a JWT payload nem titkosított, de módosítani sem lehet a szerver aláírása nélkül. Jelszót, fizetési adatot viszont soha ne tegyél bele
c) A szerver 403 Forbidden választ kell visszaadjon – a user azonosítva van, de a szerepköre (editor) nem jogosít admin funkcióra

6.

7. Helyes sorrend: D → E → F → B → A → C

8.
a) 401 Unauthorized – nincs autentikáció
b) 403 Forbidden – autentikált, de nincs joga
c) 401 Unauthorized – érvénytelen token = sikertelen autentikáció
d) 204 No Content – sikeres törlés, nincs visszaadandó tartalom