Píše se rok 2012 a web přepracoval revidovaný bezpečnostní protokol s názvem OAuth 2, který uživatelům umožňuje snadno se k webům přihlásit pomocí poskytovatelů zabezpečení. Mnoho systémů jednotného přihlášení, od AWS Cognito po Okta, implementuje OAuth. OAuth vám umožňuje „ověřit se u společnosti Google“ nebo jiných poskytovatelů na úplně jiném webu nebo v aplikaci.
Funguje to jako pivní festival. Jdete ke stolu a ověříte se svým ID (a nějakými penězi) a oni vám dají žetony. Odtud jdete ke každému pivnímu stanu a vyměníte žeton za pivo. Individuální sládek nemusí kontrolovat vaše ID ani se ptát, zda jste zaplatili. Jen si vezmou žeton a podají vám pivo. OAuth funguje stejně, ale s webem místo piva.
Je smutné, že OAuth je nejlepší pivní festival, který 2020 nabízí.
Mluvil jsem s Danem Moorem z FusionAuth o OAuth a navrhované náhradě zvané GNAP - což je pravděpodobně bez G vyslovováno jako „zdřímnutí“. Výslovnost podporuje myšlenku, že bezpečnost je opravdu vzrušující pole. GNAP řeší některá omezení OAuth a koření jej novými funkcemi.
Proč OAuth nahradit, nebo spíše rozšířit? OAuth byl navržen kolem prohlížečů. Předpokládá, že původce vytvářející požadavek zvládne přesměrování HTTP. Toto zaměření na webový prohlížeč je překážkou pro mobilní aplikace nebo jakýkoli druh „věci“ na „internetu věcí“. Navíc strany OAuth, jako je rok 2007, a vyžaduje, abyste místo formátu JSON zaúčtovali parametry formuláře.
Specifikace OAuth byla na některých místech vágní a svět se od roku 2012 změnil. Existuje spousta RFC a BCP, v podstatě doplňkové specifikace, které musíte implementovat pro více funkcí, lepší zabezpečení a obecnou kompatibilitu. Samostatné úsilí s názvem OAuth 2.1 doufá, že některé z těchto doplňků zhroutí do soudržnější jednotlivé specifikace. Některé motivace pro OAuth 2.1 najdete v Lee McGovern z příspěvku Okty „Kolik RFC vyžaduje změnu žárovky“. OAuth 2.1, na rozdíl od GNAP, je jen přírůstkové vydání bez nových významných změn kromě kombinace hromady specifikací do jediné specifikace.
Specifikace GNAP je stále v raných fázích. Autoři GNAP plánují jít dále než OAuth 2.1 a změnit povahu samotného protokolu. Místo použití parametrů HTTP můžete použít JSON. Koncové body aplikace jsou zjistitelné. Nemusíte podporovat přesměrování (nebo různé hackery kolem toho). Moore odkazuje na tyto změny pod nádherným termínem „ergonomie pro vývojáře“.
Klíčovým cílem GNAP je oddělení toho, kdo požaduje zdroje (RQ) a kdo vlastní zdroje (RO).
IETF GNAP rovněž navrhuje podporovat nové bezpečnostní funkce, jako například:
- Spuštění asynchronního a URL adresy aplikace. Jedná se o různé cesty ověřování, které klientovi umožňují ověřovat bez přesměrování. GNAP také umožňuje aplikacím ověřovat prostředky třetích stran, ke kterým server prostředků a autorizační server nemají přímý přístup.
- Žádost o pokračování. Ty umožňují klientům během procesu ověřování vyjednávat věci, jako jsou přesměrování nebo jiné podrobnosti ověřování. Umožňují také klientovi vyjednat další oprávnění nebo přístupové tokeny.
- Více přístupových tokenů. Ty umožňují klientům autentizovat se u mnoha zdrojů najednou, například jako uživatel i správce.
- Žetony omezení odesílatele. I když existují doplňky pro OAuth 2 pro tuto funkci zvanou DPOP a MTLS, GNAP by to zabudoval přímo do protokolu. Vraťte se k našemu pivnímu stanu. Co kdybychom také museli šeptat heslo do ucha prodejce, když jsme mu předávali token? Pokud by náš token byl zrušen (nebo zadržen), nevadilo by to, protože nositel by neměl heslo.
- A GNAP způsobí, že duch Kerberos křičí.
Zní to dobře? Můžete začít používat GNAP dnes? Pokud máte zájem o spolupráci, můžete rozdvojit jeden z prototypů, které šly do existujícího návrhu na GitHubu.
Podle Moora se autoři snaží vydat GNAP v roce 2022. Jelikož každý den v roce 2020 je jako týden v typickém roce, je GNAP daleko. Pracovní skupina GNAP však hledá spolupracovníky a vy se můžete připojit k seznamu e-mailů a nabídnout zpětnou vazbu a odborné znalosti. Myslím, že nemůžete opravit všechno na světě, ale můžete alespoň pomoci opravit OAuth.
