Zabezpečení moderních webových aplikací pomocí token-mediating backendu (TMB) a architektury backend-for-frontend (BFF)
Autentizace v moderních webových aplikacích je dnes typicky postavena na protokolech OAuth 2.0 a OpenID Connect (OIDC), často s využitím externího poskytovatele identity (IdP). Tyto protokoly stojí na využití access tokenů a refresh tokenů – a právě to vytváří zásadní bezpečnostní výzvu: pokud útočník tyto tokeny získá, může se vydávat za uživatele až do jejich expirace, nebo i déle.
Způsob ukládání a správy tokenů proto patří mezi nejdůležitější architektonická rozhodnutí při návrhu webové aplikace.
Jak tedy posunout bezpečnostní laťku nad rámec pouhého „správného nasazení OAuth“?
Běžný přístup: OAuth 2.0 klient v prohlížeči
Dnes doporučovaný přístup pro SPA (single-page applications) je Authorization Code Flow s PKCE, kdy JavaScriptová aplikace běžící v prohlížeči vystupuje jako OAuth klient a přebírá většinu odpovědností spojených s OAuth – včetně práce s tokeny.
Typický scénář vypadá následovně:
- prohlížeč načte aplikaci ze statického webhostingu (A);
- aplikace přesměruje uživatele k přihlášení a obdrží authorization code (B);
- aplikace vymění kód za access token (a případně refresh token) (C);
- aplikace uloží tokeny pomocí API prohlížeče;
- aplikace připojí access token k požadavkům na resource server (D) a obdrží odpovědi (E).
Při správné konfiguraci jsou tokeny do prohlížeče doručeny bezpečně. V okamžiku, kdy se však ocitnou v běhovém prostředí JavaScriptu, vzniká nová otázka: jak je bezpečně uložit?
Prohlížeč není bezpečné místo pro citlivé údaje
Moderní frameworky snižují riziko některých tříd zranitelností, ale zcela ho neodstraňují. Aplikace běžící v prohlížeči zůstávají vystaveny například:
- útokům typu Cross-Site Scripting (XSS) a DOM-based injection;
- kompromitaci závislostí (supply-chain riziko);
- škodlivým rozšířením prohlížeče;
- injektovaným skriptům v důsledku chybné konfigurace nebo kompromitovaných CDN a další.
Běžnou (a pohodlnou) praxí je ukládání tokenů do local storage. Jakýkoli JavaScript běžící v rámci vaší domény však může local storage číst. Jediný úspěšný útok tak stačí k okamžité exfiltraci tokenů.
Bezpečnější přístup: Delegovat správu tokenů na backend
Nejúčinnější strategií je vůbec tokeny do prohlížeče neposílat a delegovat jejich správu na důvěryhodnou backendovou komponentu, přičemž pro komunikaci s prohlížečem se použije zabezpečená cookie.
Tato architektura drží citlivé autentizační tokeny zcela mimo frontend a přesouvá problém z ochrany tokenů v JavaScriptu do oblasti dobře zvládnuté správy serverových session.
Session cookie nakonfigurovaná s atributy:
- HttpOnly (není čitelná z JavaScriptu),
- Secure (odesílá se pouze přes HTTPS),
- SameSite (omezuje odesílání napříč doménami),
je výrazně obtížněji zneužitelná prostřednictvím XSS než tokeny uložené v local storage.
Škodlivý kód běžící na stránce sice může během aktivní session provádět podvodné akce, zásadní rozdíl je ale v tom, že útočník nemůže odcizit znovu použitelné tokeny pro dlouhodobé vydávání se za uživatele. Dopad útoku je tak zpravidla omezen na konkrétní web a aktivní session.
Tento přístup se obvykle realizuje pomocí dvou architektonických vzorů: Token-Mediating Backend (TMB) a Backend-for-Frontend (BFF).
Backend for Frontend (BFF)
BFF je dedikovaná backendová vrstva určená pro konkrétní frontendovou aplikaci. Funguje jako důvěrný OAuth klient, provádí Authorization Code Flow, ukládá tokeny na serveru a prohlížeči vydává pouze session cookie.
Frontend nikdy nekomunikuje přímo s resource servery – vždy volá BFF. Ten při komunikaci s downstream API připojuje access token.
Základní průběh BFF:
- prohlížeč načte aplikaci ze statického hostingu (A);
- aplikace se dotáže BFF, zda existuje session (B);
- pokud ne, je prohlížeč přesměrován na BFF (C), který zahájí autorizační flow (D) a obdrží authorization code (E);
- BFF vymění authorization code za tokeny (na serveru) (F);
- BFF přiřadí tokeny k uživatelské session, nastaví session cookie a přesměruje zpět na aplikaci (G);
- odpověď vyvolá znovunačtení aplikace (H), která ověří existenci session (I) a pokračuje již v autentizovaném režimu;
- aplikace volá BFF s cookie (J), BFF volá API s access tokenem (K) a vrací výsledky (L).
Ačkoli tato architektura zvyšuje komplexitu, výrazně posiluje bezpečnost. Prohlížeč nikdy nevidí access ani refresh tokeny a spoléhá výhradně na HttpOnly session cookie, kterou nelze exfiltrovat pomocí XSS.
I pokud dojde ke spuštění škodlivého JavaScriptu, útočník nemůže „vzít tokeny a zmizet“. Může maximálně jednat v rámci aktuální session uživatele. Obnova a rotace tokenů navíc probíhá na serveru, kde lze uplatnit přísnější pravidla pro ukládání, audit i bezpečnostní politiky.
Token-Mediating Backend (TMB)
Token-Mediating Backend je odlehčená varianta zaměřená primárně na výměnu a obnovu tokenů. Refresh tokeny zůstávají na serveru a používá se session cookie, ale na rozdíl od BFF vrací access token prohlížeči a aplikace pak komunikuje s resource servery přímo.
Základní scénář:
- aplikace ověří u TMB, zda existuje session (B);
- pokud ne, prohlížeč projde autorizačním flow a vrátí authorization code TMB (C, D, E);
- TMB vymění authorization code za tokeny (na serveru) (F);
- TMB přiřadí tokeny k session, nastaví session cookie a přesměruje zpět na aplikaci (G);
- aplikace se znovu načte (H), ověří relaci (I) a získá access token;
- aplikace používá access token pro přímé volání resource serveru (J).
Token-mediating backend není tak robustní jako BFF, přesto výrazně omezuje nejhorší scénář čistě prohlížečového OAuth: krádež dlouhodobě platných tokenů prostřednictvím refresh tokenů.
Závěr
Bezpečnost autentizace vyžaduje více než jen správnou implementaci OAuth. Vyžaduje promyšlenou architekturu, která minimalizuje riziko expozice tokenů už v samotném návrhu.
Přesunem odpovědnosti za tokeny na backendovou komponentu a využitím bezpečných HttpOnly cookies pro správu session výrazně snížíte riziko exfiltrace tokenů i dlouhodobé kompromitace účtu – zejména ve srovnání s ukládáním tokenů do local storage.
Pokud je to možné, upřednostňujte BFF. Nabízí nejsilnější ochranu proti krádeži tokenů a zjednodušuje bezpečnou správu jejich životního cyklu. TMB zvažujte pouze tam, kde je proxy model BFF nepraktický (například kvůli síťové topologii, výkonovým omezením nebo specifikům legacy API) – a i tehdy jej berte jako kompromis.
Pokud chcete tyto principy zavést bez vývoje vlastní autentizační proxy, lze využít i hotové řešení, například Wren:IG které podporuje BFF přístup, pomáhá držet tokeny mimo prohlížeč a standardizovat bezpečnou správu relací.
Chcete posílit bezpečnost svých aplikací? Nechte těžkou práci na nás. Kontaktujte nás.
Zdroje: