Oblasť výpočtovej techniky prechádza neustálym vývojom, čo má za následok objavovanie sa nových problémov a samozrejme aj ich riešení. Jedným z takýchto problémov, ktorému museli svojho času čeliť veľké internetové spoločnosti ako Google a Facebook bolo, že sa začalo objavovať množstvo aplikácií tretích strán, ktoré chceli pristupovať k údajom používateľa uloženým na takomto serveri. Ako ale vyriešiť problém, kedy aplikácii nechcete zveriť svoje meno a heslo (pretože nemáte žiadnu záruku, že bude robiť len to, čo má), ale zároveň chcete, aby napríklad vedela čítať vaše fotografie? Odpoveď prišla vo forme protokolu OAuth. My sa dnes pozrieme na jeho druhú verziu.

Na pochopenie OAuth protokolu je dôležité pochopiť, čo sa vlastne chce dosiahnuť. Predstavte si, že máte účet na Facebooku, kde máte mnoho rôznych údajov. Následne si do mobilu nainštalujete aplikáciu, ktorá vám umožní prezerať si fotografie z vášho Facebook účtu. Na to, aby sa k nim dostala, potrebuje vaše meno a heslo. Vy ale neviete, či môžete tej aplikácii dôverovať. Pred chvíľou ste si ju nainštalovali a autor vám nie je povedomý. Kto zaručí, že okrem čítania fotografií neprečíta všetky vaše kontakty a niekam ich neodošle? Potrebovali by ste aplikácii dať prístup, ale len obmedzený. Určite ju nepustiť k iným údajom ako sú fotky a možno jej prístup aj celkovo časovo obmedziť. A presne na to slúži OAuth protokol.

V Aouth protokole vystupujú tieto objekty:

• Majiteľ zdrojov (Resource Owner) – to ste vy. Niekto, komu patria údaje uložené na serveri. Vy rozhodujete, aký a komu poskytnete prístup.
• Klient (Client) – to je aplikácia, ktorú ste si nainštalovali do mobilu. Bude potrebovať nejakým spôsobom získať prístup k vybraným údajom.
• Autorizačný server (Authorization server) – to je server, kde je uložený váš účet a tiež server, ktorý vie klientovi poskytnúť špeciálny token, ktorým sa dostane k zdrojom.
• Server so zdrojmi (Resource server) – to je server, na ktorom sú uložené vaše údaje. Dokáže poskytnúť údaje ktorejkoľvek aplikácii s platným špeciálnym tokenom. Môže a nemusí to byť ten istý server ako je autorizačný.

OAuth má štyri rôzne scenáre ako môže dôjsť k autorizácii klienta. Tieto sú určené pre rôzne prípady a my sa na nich o chvíľu pozrieme, ale ešte predtým si takú autorizáciu veľmi zjednodušene popíšeme:

1. Vy ako majiteľ zdrojov spustíte aplikáciu.
2. Tá potrebuje získať špeciálny token na prístup k fotografiám, a preto kontaktuje autorizačný server.
3. Autorizačný server zobrazí obrazovku, na ktorej sa viete prihlásiť a tiež potvrdiť, že klient môže pristupovať k údajom, o ktoré žiada. Je to ale obrazovka autorizačného servera, ktorú síce inicioval klient, ale inak s ňou nič nemá. Údaje (meno a heslo) teda zadávate systému, ktorému dôverujete.
4. Autorizačný server pošle klientovi naspäť špeciálny token na základe ktorého klient vie zo servera so zdrojmi získať údaje.

Hlavna myšlienka je, že klientovi neodovzdávate svoje meno a heslo, ale prihlasujete sa stále na stránke, ktorá váš účet vlastní (teda Google, Facebook atď.) a ona potom len klientovi vytvorí špeciálny token, ktorým sa vie dostať k obmedzenej množine vaších údajov. Všetkému tomu ale musí predchádzať registrácia klienta na autorizačnom serveri (čo robí najčastejšie tvorca tohto klienta), pričom pri tejto registrácii sa vygenerujú tzv. Client secret a Client Id, ktoré sa následne používajú v komunikácii medzi klientom a autorizačným serverom.

Ako som spomenul vyššie, existujú štyri rôzne scenáre:

1. Server-Side Web Application Flow – určené pre web klientov, ktorých hlavná logika je na serveri. Teda napríklad PHP. V takom prípade browser od autorizačného servera získava len tzv. Authorization code, ktorý je ešte serverom klienta vymieňaný za Access token v druhej komunikácii s autorizačným serverom.
2. Client-Side Web Application Flow – určené pre web klientov, ktorých hlavná logika je na strane klienta – teda v prehliadači. Napríklad JavaScriptové stránky. Vtedy klient získava priamo Access token na prístup k údajom.
3. Resource Owner Password Flow – v tomto prípade klientovi poskytujete meno a heslo, ale on ich neukladá (nemal by), ale vymení ich za Access token pre komunikácii s autorizačným serverom. Akú to má výhodu? Napríklad tú, že ak si zmeníte heslo na serveri s účtami, táto aplikácia s tým nebude mať problém (na rozdiel od prípadu, kedy si kópiu mena a hesla uchová vo svojej databáze).
4. Client Credentials Flow – v tomto prípade je Resource Owner aplikácia a vy ako používateľ ani neviete, že dochádza k výmene údajov s autorizačným serverom. Používa sa pre klientov s vysokým stupňom dôvery.

Komunikácia medzi klientom a autorizačným serverom môže prebiehať tiež pomocou digitálne podpísaných správ. V protokole je to ale voliteľná súčasť, čo vyvolalo tiež kritiku.

Ak to nebolo z doterajších informácií jasné, tak OAuth rieši autorizáciu – teda to, či má niekto právo pristupovať k určitým údajom. Pre riešenie autentifikácie (identifikácie toho, kto ste a či ste to naozaj vy) slúži rozšírenie OpenID Connect (nemýliť s OpenID – nie je to to isté), čo je samostatná časť špecifikácie, ktorú môžete a nemusíte použiť.

OAuth je výsledkom situácie, že internet je plný aplikácií, ktoré sú cudzie, ale ktoré zároveň vyžadujú určitý stupeň prístupu k vaším údajom, aby mohli fungovať. Keďže s narastajúcim počtom používateľov internetu a počtom aplikácií je tento problém stále viac a viac rozšírený, aj OAuth zaznamenal v posledných rokoch nárast v používaní. Pre väčšinu rozšírených programovacích jazykov už existujú hotové knižnice, ktoré vám umožňujú implementovať autorizačný server, aj server so zdrojmi. Tiež veľký poskytovatelia autorizácie ako Google, Facebook alebo Microsoft zverejnili knižnice, ktoré umožňujú protokol jednoducho používať na strane klientskej aplikácie. V takom prípade len treba byť pripravený na určité rozdiely v implementácii, ktoré nie sú špecifikáciou dobre pokryté.