Comments 14
А еще можно использовать, например, KeyCloak. Инструкция для nginx. Поддерживает, наверное, почти все способы входа.
Для тех, кто не хочет связываться с таким большм комбайном (или не осилил, как я пока что), есть OAuth2-Proxy, который позволяет настроить авторизацию немного попроще.
Плюсы - хорошо развивается, много фич. Минусы - иногда развивается "слишком" быстро и ломает обратную совместимомть при крупных релизах, не все понятно в документации.
К чему я это - не обязательно (а часто даже вредно) писать свою собственную реализацию, а потом пытаться продать ее кому-то, если есть уже готовые решения.
Я разве что то продаю?
А логика "не создавать других решений если есть одно" вообще странная. По ней, если есть KeyCloak то не нужнен OAuth2-Proxy ?
Для себя, конечно, можете написать. Но важно понимать минусы использования. Конечно, "фатальный недостаток" (с) есть у каждого стороннего приложения.
Моя претензия конкретно к вашей статье - вы сами разобрались, но по статье что-то новое узнать довольно сложно, вдобавок не освещены много важных моментов.
Например, конфигурация nginx - как вы предлагаете вообще его использовать? Не мешало бы привести пример конфига. Что будет если location настроен слишком широко и каждый запрос (включая статику) тоже будет требовать авторизации? Каждый запрос будет ходить на этот сервис? Существуют решения, которые ставят, например, cookie на какой-то период чтобы избежать такого оверхеда (oauth2-proxy так делает).
Если вы делаете API, то очень бы рекомендовалось выпустить спецификацию в виде, например, OpenAPI конфига.
Как у вас решены (никак) вопросы с безопасностью - MITM, DDoS, etc?
А логика "не создавать других решений если есть одно" вообще странная. По ней, если есть KeyCloak то не нужнен OAuth2-Proxy ?
У вас нет ни внятной документации, ни тестов, ни нормальной процедуры конфигурирования. Вы не будете же распространять тот код что у вас написан? Версия 0.0.7, да, это оправдывает. Использовать в каких-то более крупных системах это тоже преждевременно. oauth2-proxy - решение более зрелое и является альтернативой тому же KeyCloak (и другим сервисам). Между ними я могу выбирать.
Еще раз - моя претензия именно к статье. Она сыровата и малоинформативна. Конечно же, это лично мое мнение. Простите если я слишком резко высказался. Вы сами просили комментарии.
Настройка Nginx выходит за рамки данного решения - если его убрать/заменить в приложении ничего не изменится. Если же этот участок (между клиентом и приложением) не был описан - место и цель использования приложения будет не верно понято.
Нет смысла рассматривать данное приложение как решение для энтерпрайз, не совсем понятно откуда требования такие, спецификации, тонна документации. На 300 строк кода?
Данное приложение как раз для тех случаев, когда не хочется тратить время попытки "осилить большие комбайны".
KeyCloak больше нужен для создания SSO, когда в компании много разных сервисов со своим, условно говоря, back-office. Для микросервисной архитектуры одного приложения он особо-то и не нужен (я бы даже сказал, слишком избыточен). А вот схема, которую реализовал автор вполне себе подойдёт. Мы у себя что-то похожее реализовали для front-office
Тоже на node.js и nginx реализовали ?
Статья про аутентификацию для желающих испачкать руки, однако повторять подобное ни для самообразования, ни с целью уменьшить количество зависимостей не стоит. Система лишь очень отдалённо напоминает то что можно было бы запустить в прод. а если попытаться реализовать в ней хоть минимально-допустимый функционал, станет очевидно что это отнюдь не так "удобно" как подаётся автором.
Из банального - каждый вызов API превращается в 2-3 вызова к (возможно) внешней системе. COTS OpenID Connect решения кешируют приватные ключи пользователя и валидируют JWT локально. Накладные расходы - локальная расшифровка base64, хеширование и проверка хеша. Никаких внешних вызовов.
Что из себя представляет приватный ключ пользователя это тоже очень важный вопрос который автор обходит его стороной. Наивная система использует один приватный ключ для всех пользователей. Его просто хешировать, но узнав его, Чарли получит доступ ко всем пользовательским аккаунтам. Умная система реализует более комплексную политику генерации и инвалидации ключей для пользователей и групп пользователей.
Из забавного, у автора очень наивное понимание "удобства":
В примере используется собственный модуль просто для удобства. -- Нет, удобно следовать общепринятому стандарту и использовать готовый OpenID Connect, WebAuthn или один из сотен доступных поставщиков. Писать собственный велосипед очень увлекательно, но ни в коем случае не удобно.
Для удобства и простоты демонстрации используется Json Web Token (JWT). -- JWT с одним полем не имеет никаких преимуществ перед обычной session cookie. Автор, удобства ради, обернул обычную куку в base64 и JSON.
Да и "идентификация и аутентификация" в контексте данной статьи совершенно абсурдны. Вероятно автор подразумевает аутентификациию и авторизацию, но это не важно, потому что ни про идентификацию, ни про авторизацию в статье ничего не написано.
Большое спасибо, вы более развернуто объяснили то что не смог я. Все совершенно правильно.
Боюсь что авторизация это как раз не на этом этапе, а там, куда дальше уходит запрос ( на схеме "API"). В самом приложении "AUTH" только аутентфикация.
Смысл слов "используется для удобства" - в том смысле что нет никакой привязки к нему, можно использовать вместо него что либо другое, хоть http node.js - кий, хоть express.
Данное решение не отрицает ни один из стандартов, это именно приложение, с помощью которого можно реализовать как собственную реализацию (от банального проверки пароля) до всех других протоколов.
JWT и cookie - это все таки разные вещи)) просто в данном случае в jwt не вкладывается ничего лишнего, это дает гибкость в оперировании данными, представьте что какой то микросервис хочет дополнить данные пользователя - ДО того как он обратиться к сервису. (просто пример)
Про "приватный ключ" совсем не понял, честно говоря, это не из статьи?
Насчет в "прод" - ну я то использую, мне удобно чем каждый раз в проекты тащить что то большое, тут конфиг подправил и готово.
Но спасибо, хотя бы понял что статью надо дополнить и расжевать.
Претензии не к подходу. Под личные хотелки можно хоть собственныую ОС написать, и у этого даже будут некоторые преимущества. Претензии к тому что на хабре лежит статья которая учит что так делать круто.
Не круто. Автор не понимает даже чем JWT отличается от сессионных кук и зачем они вообще нужны (для этого достаточно вступление в википедии прочитать), но предлагает читателям более "удобный" костыль. Кто-то это даже лайкает, добавляет в закладки и возможно даже будет использовать.
P.S. ")))" весьма детский аргумент. "У меня работает" тоже.
Мне жаль, но, тут, вероятно, опыт сдерживает понимание.
Попробую разъяснить,
jwt в данном случае вообще не имеет значения, он не объект статьи и не тема. На его месте в схеме может быть хоть cookie, хоть что угодно. В статье указано что он (jwt) пустой (без полезных данных) исключительно чтобы не отвлекать, "для удобства и простоты демонстрации"., так понятнее? То есть никто не запрещает потом туда включать полезные данные.
Но если jwt пустой, то он не становится решением равнозначным cookie, потому что никто же не будет менять решение каждый раз под определенные параметры?
Опять же статья не о jwt, он здесь для показа возможности связки приложения с внешними данными.
Осталось надеятся что в проде вы нигде не забываете заменить XlSklNDEtGXHpbkkX6ri7Fqj на новое случайное значение. А то, знаете, misconfig всякий бывает ,)
Nginx + Node.js: делаем идентификацию и аутентификацию