GNAP: OAuth следващото поколение

Годината беше 2012 г. и ревизиран протокол за сигурност, наречен OAuth 2, обхвана мрежата, позволявайки на потребителите да използват доставчици на сигурност, за да влизат лесно в уебсайтове. Много системи за единичен вход, от Cognito на AWS до Okta, прилагат OAuth. OAuth е това, което ви позволява да „удостоверите с Google“ или други доставчици на съвсем различен уебсайт или приложение.

Работи като бирен фестивал. Отиваш на бюро и удостоверяваш с идентификационния си номер (и малко пари) и те ти дават жетони. Оттам отиваш до всяка бирена палатка и обменяш жетон за бира. Отделният пивовар не трябва да проверява вашата лична карта или да пита дали сте платили. Те просто вземат жетона и ви връчват бира. OAuth работи по същия начин, но с уебсайтове вместо бира.

За съжаление, OAuth е най-добрият бирен фестивал 2020, който може да предложи.

Говорих с Дан Мур от FusionAuth за OAuth и предложена замяна, наречена GNAP - което вероятно се произнася без G като „дрямка“. Произношението продължава идеята, че сигурността е наистина вълнуващо поле. GNAP адресира някои ограничения на OAuth и го подправя с нови функции.

Защо да заменим или по-скоро да увеличим OAuth? OAuth е проектиран около браузъри. Предполага се, че инициаторът, отправящ заявката, може да се справи с HTTP пренасочване. Този фокус на уеб браузъра е препъни камък за мобилни приложения или всякакъв вид „неща“ в „Интернет на нещата“. Освен това OAuth страни като 2007 г. и изисква да публикувате параметри на формуляра вместо JSON.

Спецификацията на OAuth беше неясна на някои места и светът се промени от 2012 г. Има множество RFC и BCP, по същество допълнителни спецификации, които трябва да внедрите за повече възможности, по-добра сигурност и обща съвместимост. Отделно усилие, наречено OAuth 2.1, се надява да срине някои от тези добавки в по-съгласувани единични спецификации. За някои от мотивациите за OAuth 2.1 вижте Лий Макгавърн от публикацията на Окта „Колко RFC са необходими, за да сменим електрическа крушка“. OAuth 2.1, за разлика от GNAP, е само постепенно освобождаване без нови значителни промени освен комбинирането на стека от спецификации в една спецификация.

Спецификацията на GNAP все още е в начален етап. Авторите на GNAP планират да отидат по-далеч от OAuth 2.1 и да променят естеството на самия протокол. Вместо да използвате HTTP параметри, можете да използвате JSON. Крайните точки на приложението са откриваеми. Не е нужно да поддържате пренасочвания (или различните хакове около това). Мур се позовава на тези промени под възхитителния термин „ергономия за разработчици“.

Основна цел на GNAP е разделянето на това кой иска ресурсите (RQ) и кой притежава ресурсите (RO).

IETF

GNAP предлага също така да поддържа нови функции за сигурност като:

  • Стартиране на асинхронен и URL адрес на приложение. Това са различни пътища за удостоверяване, които позволяват на клиента да се удостоверява без пренасочване. GNAP също така позволява на приложенията да се удостоверяват пред ресурси на трети страни, до които сървърът за ресурси и сървърът за оторизация нямат пряк достъп.
  • Поискайте продължения. Те позволяват на клиентите да договарят неща като пренасочвания или други подробности за удостоверяване по време на процеса на удостоверяване. Те също така позволяват на клиента да договаря допълнителни привилегии или жетони за достъп.
  • Токени за множествен достъп. Те позволяват на клиентите да се удостоверяват за много ресурси наведнъж, например като потребител и администратор.
  • Токени за ограничение на изпращача. Въпреки че има добавки към OAuth 2 за тази функционалност, наречена DPOP и MTLS, GNAP ще вгради това директно в протокола. Върнете се на нашия пример за бирена палатка. Ами ако трябва да прошепнем и парола в ухото на продавача, докато им връчваме жетона? Ако нашият маркер беше изпуснат (или прихванат), нямаше да има значение, защото приносителят нямаше да има паролата.
  • И GNAP кара духа на Керберос да крещи.

Звучат добре? Можете ли да започнете да използвате GNAP днес? Ако се интересувате от сътрудничество, можете да разклоните един от прототипите, влезли в съществуващото предложение на GitHub.

Според Мур авторите се стремят да пуснат GNAP през 2022 г. Тъй като всеки ден през 2020 г. е като седмица в типична година, GNAP е далеч. Работната група на GNAP обаче търси сътрудници и вие можете да се присъедините към пощенския списък и да предложите вашите отзиви и опит. Предполагам, че не можете да поправите всичко на света, но поне можете да помогнете за поправянето на OAuth.