OAuth 2.0
OAuth 2.0 (RFC 6749) je moderní autorizační protokol (resp. framework), který se stal de facto standardem pro zabezpečení RESTových webových služeb.
Jeho hlavní výhoda tkví v tom, že uživatel může poskytnout klientské aplikaci (např. Twitter klientu) přístup k jeho datům v nějaké službě (např. Twitteru), aniž by té aplikaci musel vyzradit své přístupové údaje do služby, a tím ji poskytl prakticky neomezený přístup k jeho účtu. Dále umožňuje podrobně vymezit pravomoci jednotlivých klientských aplikací (pomocí tzv. scopes) a detailně sledovat využívání poskytnutých privilegií. Klientská aplikace se může autentizovat jak sama za sebe, tak i „za jejího uživatele“, který k tomu dá explicitní souhlas. Díky tomu lze bez rizika narušení ochrany osobních údajů umožnit přístup k citlivým datům uživatelů např. i studentským aplikacím – dostanou se pouze k té podmnožině dat, ke kterým jim dá jejich uživatel explicitní souhlas (např. jeho studijní výsledky). Zároveň je principiálně jednoduchý, takže se snadno integruje.
Nově vznikající fakultní back-end služby jsou zabezpečeny právě tímto protokolem.
Popis rolí
OAuth 2.0 definuje čtyři druhy rolí:
- resource owner (uživatel) – vlastník chráněného zdroje (dat), entita schopná přidělit nebo odepřít přístup ke chráněnému zdroji (typicky se jedná o koncového uživatele);
- resource server (služba) – poskytovatel a hostitel chráněného zdroje, entita schopná obsluhovat požadavky (obsahující access token) ke chráněnému zdroji (typicky se jedná o serverovou službu vystavující API);
- client (klient) – aplikace, která přistupuje ke chráněnému zdroji na resource serveru s oprávněními resource ownera (uživatele);
- authorization server (autorizační server) – server, který klientovi vydává access token v případě jeho úspěšné autentizace od resource ownera (uživatele) a získání autorizace (autorizační server může být přímo součástí resource server, nebo oddělený).
Autorizační server
Vyvíjíme vlastní OAuth 2.0 autorizační server, který se jmenuje Zuul OAAS (dále jen OAAS). Jedná se o samostatný OAAS, tzn. není součástí vlastní služby vystavující API (resource server), ale více samostatných služeb může využívat jeden (vzdálený) OAAS, který vydává a validuje tokeny.
OAAS běží na adrese https://auth.fit.cvut.cz/ a může ho využívat kdokoli z akademické obce ČVUT (nejen FIT). Adresy jednotlivých „endpointů“ jsou následující:
- Authorization Endpoint: https://auth.fit.cvut.cz/oauth/authorize
- Token Endpoint: https://auth.fit.cvut.cz/oauth/token
- Check Token Endpoint: https://auth.fit.cvut.cz/oauth/check_token
Pro vývojáře klientských aplikací (client)
Chcete-li využít fakultní služby (např. KOSapi, VVVSapi, USERapi, …) ve své aplikaci, postup je velmi jednoduchý.
- Přihlaste se do AppsManager.
Vytvořte nový projekt a v něm novou aplikaci. Získáte client_id a client_secret (zjednodušeně jméno a heslo vaší aplikace).
Důležité:
Specifikace RFC 6749 důrazně nedoporučuje zasílání client_id a client_secret v tělech požadavků zasílaných na autorizační server. Pro předání těchto údajů autorizačnímu serveru využijte Basic HTTP Authentication Scheme.
- V nabídce služeb si aktivujte scopes, které chcete využívat.
Pokud svou aplikaci implementujete v nějakém JVM jazyku (Java, Groovy, Scala) s využitím Spring Frameworku, určitě vám přijdou vhod jednoduché ukázkové aplikace v repositáři cvut/zuul-samples využívající Spring Security OAuth. Není-li tohle váš šálek kávy, nemusíte zoufat, existuje spousta dalších knihoven. A ostatně, máte-li HTTP klient, tak napsání vlastní podpory OAuth 2.0 pro klienta je otázka pár řádek kódu. Jde pouze o poslání pár HTTP požadavků na definované adresy, žádná kryptografie. Popis komunikace pro jednotlivé autorizační granty lze nalézt přímo v RFC 6749.
Pro vývojáře služeb (resource server)
OAuth 2.0 standard sice umožňuje, aby OAAS a resource provider (služba) byly dvě oddělené komponenty, ale už nespecifikuje, jak spolu budou v takovém případě komunikovat. Nicméně řešení je zřejmé. Služba od klienta dostane přístupový token a pouze musí ověřit, zda je tento token validní (tzn. vydal ho daný OAAS, není prošlý atd.) Zuul OAAS tedy vystavuje tzv. Check Token endpoint, který službám slouží pro ověření tokenu a získání několika základních informací o tom, pro koho byl vydán apod.
Implementujete-li službu v nějakém JVM jazyku (Java, Groovy, Scala) s využitím Spring Frameworku, máte už práci velmi usnadněnou. Stačí použít Spring Security OAuth a naši knihovnu zuul-spring-support (ještě ve vývoji), ve které je již vše připraveno. V repositáři cvut/zuul-samples pak najdete jednoduchou ukázkovou aplikaci.