Autentizace říká, kdo je přihlášený uživatel. Způsobů autentizace můžete mít několik vedle sebe. Jeden asi bude jménem a heslem – uživatel zadá na formuláři jméno a heslo, vy ho podle jména v databázi vyhledáte a ověříte heslo. Když použijete přihlašování přes třetí stranu (např. Facebook), při registraci si opět uložíte údaje o uživateli do databáze, pak ho necháte přihlásit se přes Facebook a Facebook vám vrátí nějaký (pro Facebook) unikátní identifikátor toho uživatele. A ten vy si uložíte k tomu uživatelskému profilu do databáze. Když se příště přihlásí přes Facebooku, Facebook vám zase vrátí to samé ID a podle toho vy si v databázi najdete, který je to uživatel. Takže v databázi budete mít nejspíš nějakou tabulku s uživatelským profilem (třeba jeho jméno, příjmení a e-mail), vedle toho jinou tabulku se jménem a heslem a další tabulku s ID z Facebooku. A k jednomu profilu můžete mít uložený jak záznam v tabulce se jménem a heslem, tak záznam v tabulce Facebooku – uživatel si pak může vybrat, kterou variantou se přihlásí.
HTTP je ale bezstavový protokol, tedy normálně by uživatel musel zadávat své jméno a heslo (nebo se přihlašovat přes Facebook) s každým požadavkem, který se pošle na server. To samozřejmě nikdo dělat nebude – místo toho server uživatele ověří jednou a na základě toho předá klientovi nějakou informaci, kterou pak klient posílá s každým dalším požadavkem. A podle ní server pozná, že jde o toho přihlášeného klienta. Dříve se to dělalo tak, že server přidělil přihlášenému uživateli nějaké unikátní číslo (nazývané třeba session ID), a někam si poznamenal, že tohle session ID je uživatel třeba Franta Novák. Pak session ID poslal klientovi a ten ho přidával jako cookie do každého dalšího požadavku na server. Server si podle toho session ID z cookie dohledal příslušný záznam a z něj si přečetl, že s tímhle session ID je přihlášený uživatel Franta Novák. To má tu nevýhodu, že musí být na serveru to úložiště session ID, takže můžete mít jenom jeden server, nebo – když jich máte víc – potřebujete mezi nimi sdílet to úložiště session ID.
A tady do toho vstupuje ten OAuth2 protokol. Místo toho, aby si server poznamenával session ID, tak vytvoří elektronický dokument (ve formátu JSON), který říká „přihlášený uživatel je Franta Novák“, a případně k tomu doplní další údaje. A tenhle dokument elektronicky podepíše a pak ho i s tím podpisem předá klientovi. Klient pak ke každému požadavku nepřidává session ID, ale tenhle elektronicky podepsaný dokument, kterému se říká (autentizační) token (ve skutečnosti je velmi krátký, desítky znaků). Když ho dostane server, ověří ten podpis, a pokud sedí, ví, že může důvěřovat té informaci „přihlášený uživatel je Franta Novák“. Tím pádem si server nemusí pamatovat žádné session ID, ale i když budete mít 80 serverů po celém světě, pokud bude každý z nich umět ověřit ten elektronický podpis, dokáže bezpečně zjistit, že jde o toho správného uživatele.
Ve vašem případě je pro tu autentizaci REST požadavků OAuth2 trochu kanón na vrabce, ale je to průmyslový standard, se kterým umí zacházet spousta knihoven a frameworků. A Spring už má podporu v sobě, takže nemusíte nic implementovat, jenom to nakonfigurujete. V dokumentaci Springu
Spring Security Reference jsou ty varianty použití OAuth2 popsané.
Druhá věc je, že OAuth2 se používá i přitom přihlašování třeba přes Facebook, ale to s tou autentizace REST požadavků nesouvisí. Vlastně byste tam měl OAuth2 použité na dvou nesouvisejících místech – pro přihlášení přes Facebook a pro autentizaci REST požadavků.
Aby vám fungovala anotace
@Secured(role), musíte implementovat rozhraní
UserDetailsService, kde je metoda, která vrací uživatele a jeho role. Ve vašem případě je nejjednodušší podle předaného identifikátoru si uživatele dohledat v databázi a z ní načíst i odpovídající role.
S OAuth2 by se to dalo udělat i tak, že se ty role načtou při přihlášení uživatele a přidají se do toho autentizačního tokenu, který se pak posílá s každým požadavkem. Díky tomu podpisu pak server ví, že tomu seznamu rolí může důvěřovat. To se ale používá spíš v případech, kdy máte oddělený server, který dělá autentizaci, a server, který poskytuje vlastní služby. Ten server pak nemusí vědět nic o uživatelích, prostě se jenom řídí tím, co je v tom tokenu.
92 Odpovědí
69408 Zhlédnutí