Co je to OAuth? Definice a jak funguje

O prozrazování hesel a o tom, že byste to nikdy neměli dělat, jsme již mluvili. Když chce webová stránka využívat služby jiné webové stránky – například když Bitly zveřejňuje příspěvky do vašeho streamu na Twitteru – místo toho, aby vás požádala o sdílení hesla, měla by místo toho použít protokol zvaný OAuth.

Je důležité pochopit, jak vás může program, webová stránka nebo aplikace ověřit jako uživatele – má správná oprávnění? Poskytli jste jim nějaký způsob, jak ověřit, kdo jste – a jak vaším jménem přistupovat k datům? OAuth pomáhá tento proces zefektivnit: ale i v případě automatizace si vždy uvědomte, jak daná osoba nebo společnost používá (nebo ukládá) vaše data.

Co je to OAuth?

OAuth je otevřený standardní autorizační protokol nebo rámec, který poskytuje aplikacím možnost „bezpečného určeného přístupu“. Například můžete Facebooku sdělit, že ESPN.com může přistupovat k vašemu profilu nebo zveřejňovat aktualizace na vaší časové ose, aniž byste museli ESPN sdělit své heslo k Facebooku. Tím se významným způsobem minimalizuje riziko:

OAuth nesdílí údaje o heslech, ale místo toho používá autorizační tokeny k prokázání identity mezi spotřebiteli a poskytovateli služeb. OAuth je ověřovací protokol, který umožňuje schválit interakci jedné aplikace s jinou vaším jménem, aniž byste museli prozradit své heslo.

SAML vs. OAuth

SAML (Security Assertion Markup Language) je alternativní standard federativního ověřování, který mnoho podniků používá pro jednotné přihlášení (SSO). SAML umožňuje podnikům sledovat, kdo má přístup k podnikovým zdrojům.

Mezi SAML a OAuth je mnoho rozdílů. Protokol SAML používá k předávání zpráv jazyk XML, zatímco protokol OAuth používá JSON. Protokol OAuth poskytuje jednodušší mobilní prostředí, zatímco SAML je zaměřen na zabezpečení podniků. Tento poslední bod je klíčovým rozdílem: To je důvod, proč mobilní aplikace, moderní webové aplikace, herní konzole a zařízení internetu věcí (IoT) považují protokol OAuth za lepší řešení pro uživatele. SAML naproti tomu vhazuje do prohlížeče soubor cookie relace, který uživateli umožňuje přístup k určitým webovým stránkám – skvělé pro krátkodobé pracovní dny, ale ne tak skvělé, když se musíte každý den přihlašovat k termostatu.

Příklady OAuth

Nejjednodušším příkladem OAuth v akci je, že jeden web řekne: „Hej, nechcete se přihlásit na náš web pomocí přihlašovacích údajů jiného webu?“. V tomto scénáři chce první webová stránka – říkejme této webové stránce spotřebitel – vědět pouze to, že uživatel je stejný uživatel na obou webových stránkách a že se úspěšně přihlásil k poskytovateli služby – což je stránka, ke které se uživatel původně přihlásil, nikoli spotřebitel.

Dobrým příkladem použití protokolu OAuth jsou aplikace Facebook. Řekněme, že používáte aplikaci na Facebooku a ta vás požádá o sdílení vašeho profilu a fotografií. Facebook je v tomto případě poskytovatelem služby: má vaše přihlašovací údaje a vaše obrázky. Aplikace je spotřebitelem a vy jako uživatel chcete pomocí aplikace něco udělat se svými obrázky. Konkrétně jste této aplikaci poskytli přístup ke svým obrázkům, které OAuth spravuje na pozadí.

Vaše chytrá domácí zařízení – toustovač, termostat, bezpečnostní systém atd. – pravděpodobně používají nějaký druh přihlašovacích údajů k vzájemné synchronizaci a umožňují vám spravovat je z prohlížeče nebo klientského zařízení. Tato zařízení používají to, čemu se v protokolu OAuth říká důvěrná autorizace. To znamená, že uchovávají informace o tajném klíči, takže se nemusíte znovu a znovu přihlašovat.

Vysvětlení protokolu OAuth

OAuth je o autorizaci, nikoli o ověřování. Autorizace je žádost o povolení k provádění činností. Autentizace je o prokázání, že jste správná osoba, protože věci znáte. OAuth nepředává autentizační údaje mezi spotřebiteli a poskytovateli služeb – místo toho funguje jako jakýsi autorizační token.

Častým přirovnáním, které jsem při zkoumání OAuth viděl, je klíč od vašeho auta. Klíč od vozu umožňuje obsluze nastartovat a pohybovat autem, ale nedává jí přístup do kufru ani do přihrádky.


Tken OAuth je jako tento klíč od vozu. Jako uživatel můžete spotřebitelům říci, co mohou od jednotlivých poskytovatelů služeb používat a co ne. Každému spotřebiteli můžete dát jiný valet key. Nikdy nemají k dispozici úplný klíč ani žádné soukromé údaje, které jim umožňují přístup k úplnému klíči.

Jak funguje OAuth

V transakci OAuth jsou tři hlavní hráči: uživatel, spotřebitel a poskytovatel služby. Tento triumvirát byl láskyplně nazván milostným trojúhelníkem OAuth.

V našem příkladu je Joe uživatelem, Bitly je spotřebitelem a Twitter je poskytovatelem služby, který ovládá Joeův zabezpečený zdroj (jeho stream na Twitteru). Joe by chtěl, aby služba Bitly mohla zveřejňovat zkrácené odkazy na jeho stream. Takto to funguje:

Krok 1 – Uživatel projeví záměr

  • Joe (uživatel):
  • Bitly (Spotřebitel): „Ahoj, Bitly, chtěl bych, abys mohl posílat odkazy přímo do mého streamu na Twitteru.“
  • Bitly (Spotřebitel): „Ahoj, Bitly: (Bitly) (uživatel): „Skvělé! Půjdu požádat o povolení.“

Krok 2 – Spotřebitel získává povolení

  • Bitly: „Mám uživatele, který by chtěl, abych publikoval v jeho streamu. Mohu dostat token požadavku?“
  • Twitter (poskytovatel služby): „Jistě. Tady je token a tajemství.“

Tajemství se používá k zabránění falšování požadavků. Spotřebitel používá tajemství k podpisu každého požadavku, aby poskytovatel služby mohl ověřit, že skutečně pochází z aplikace spotřebitele.

Krok 3 – Uživatel je přesměrován na poskytovatele služby

  • Bitly: „OK, Joe. Posílám tě na Twitter, abys to mohl schválit. Vezmi si s sebou tento token.“
  • Joe: „OK!“

<Bitly přesměruje Joea na Twitter k autorizaci>

Tohle je ta děsivá část. Pokud by Bitly byla superstrašidelná společnost Evil Co. mohla by zobrazit okno, které by se tvářilo jako Twitter, ale ve skutečnosti by bylo phishingem pro vaše uživatelské jméno a heslo. Vždy si ověřte, že adresa URL, na kterou jste přesměrováni, je skutečně adresa poskytovatele služby (v tomto případě Twitteru).

Krok 4 – Uživatel uděluje povolení

  • Joe: „Twitter, rád bych autorizoval tento token požadavku, který mi dal Bitly.“
  • Twitter: „
  • Joe: „Ano!“
  • Twitter: „

Twitter označí token žádosti jako „good-to-go“, takže když spotřebitel požádá o přístup, bude přijat (pokud je podepsán pomocí jeho sdíleného tajemství).

Krok 5 – Spotřebitel získá přístupový token

  • Bitly: „Twitter, mohu vyměnit tento token žádosti za přístupový token?“
  • Twitter: „

Krok 6 – Spotřebitel získá přístup k chráněnému prostředku

  • Bitly: „Jistě: „Rád bych zveřejnil tento odkaz na Joeův stream. Tady je můj přístupový token!“
  • Twitter: „Hotovo!“

V našem scénáři Joe nikdy nemusel sdílet své přihlašovací údaje ke službě Twitter se službou Bitly. Prostě jen bezpečným způsobem delegoval přístup pomocí protokolu OAuth. Joe se může kdykoli přihlásit na Twitter a zkontrolovat přístup, který udělil, a odebrat tokeny pro konkrétní aplikace, aniž by to ovlivnilo ostatní. Protokol OAuth také umožňuje granulární úrovně oprávnění. Můžete dát Bitly právo publikovat na svém účtu Twitter, ale omezit LinkedIn na přístup pouze pro čtení.

OAuth 1.0 vs. OAuth 2.0

OAuth 2.0 je kompletně přepracovaný oproti OAuth 1.0 a obě verze nejsou kompatibilní. Pokud dnes vytváříte novou aplikaci, použijte OAuth 2.0. Tento blog se týká pouze OAuth 2.0, protože OAuth 1.0 je zastaralý.

OAuth 2.0 je rychlejší a jednodušší na implementaci. OAuth 1.0 používal složité kryptografické požadavky, podporoval pouze tři toky a nebyl škálovatelný.

OAuth 2.0 má naopak šest toků pro různé typy aplikací a požadavky a umožňuje podepsané tajemství přes HTTPS. Tokeny OAuth již nemusí být ve verzi 2.0 šifrovány na koncových bodech, protože jsou šifrovány při přenosu.

Další zdroje

Doufejme, že toto byl dobrý úvod do problematiky OAuth, takže až příště uvidíte „Přihlášení pomocí Twitteru“ nebo podobné delegované ověřování identity, budete mít dobrou představu, o co jde.

Pokud se chcete do mechaniky OAuth ponořit hlouběji, zde je několik užitečných odkazů:

  • http://marktrapp.com/blog/2009/09/17/oauth-dummies
  • https://dev.twitter.com/docs/auth/oauth/faq
  • http://stackoverflow.com/questions/4113934/how-is-oauth-2-different-from-oauth-1
  • http://googlecodesamples.com/oauth_playground/

.

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna.