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 (grant Client Credentials), tak i „za jejího uživatele“ (grant Authorization Code), 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 (dále jen OAAS), který se jmenuje Zuul OAAS. Samozřejmě je open-source a najdete ho na GitHubu. 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, Usermap API, …) ve své aplikaci, postup je velmi jednoduchý.

1. Přihlaste se do AppsManager.
2. 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).
3. 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 najdete např. tady nebo přímo v RFC 6749.

Pro vývojáře služeb (resource server)

Vytváříte nějakou fakultní službu vystavující RESTful API a rádi byste ji zabezpečili OAuth 2.0 protokolem? Napište mi!

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. CheckToken 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. Úplný popis najdete opět v repositáři zde.

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.