Learn-json-web-tokens: Опасная и неверная информация в README

Некоторые очень хорошо продуманные и четко выраженные опасения, безусловно, дают мне пищу для размышлений как человека, который только начал изучать репо. Я искал быстрый пример для создания рабочего примера аутентификации JWT с помощью Node. Меня интересует JWT, чтобы предоставить современный передовой подход к управлению сеансами как для REST API, так и для js-клиента, избегая при этом проблем с CORS. Меня слегка интересует безопасность, но это не моя мотивация для использования JWT, хотя я ценю роль, которую токены могут играть в более всеобъемлющих безопасных подходах, таких как OAUTH. Когда я впервые прочитал это репо, он действительно поразил меня тем, что он включает в себя множество заметок, которые автор собрал по мере того, как они накапливают свои знания об использовании JWT и т. Д. Хотя у меня мало инвестиций в это репо, я склонен полагать, что существует место для конкретной платформы, минималистичный рабочий пример входа / выхода с некоторыми вспомогательными инструментами, ссылками. Я считаю, что цели этого репо хороши в качестве основы для навыков адаптации и в качестве стартера, но, возможно, README действительно нуждается в серьезном переписывании и переориентации на цели такого типа использования JWT. Я был бы счастлив попытаться предложить что-нибудь ... joepie91 - вы явно хорошо разбираетесь в проблемах ... не могли бы вы поделиться некоторыми мыслями о том, каковы реальные преимущества такого использования JWT?

Привет @ joepie91 , мы _stoked_, что вы нашли и _ прочитали_ наши заметки о JWT!
Спасибо, что нашли время открыть этот вопрос и выразить свою обеспокоенность. ❤️
Мы были бы _ рады_, если бы вы разбили каждую из своих проблем на _ отдельные_ проблемы или хотя бы пронумеровали их, чтобы их было легче обсудить.

Мы _ уважительно_ не согласны с тем, что содержание этих заметок является «_ опасным_».

_Cookies _> в Директиве EU ePrivacy Recital 25 , cookies _ прямо упоминаются _ 5 раз:

видеть:
https://en.wikipedia.org/wiki/Directive_on_Privacy_and_Electronic_Communications#Cookies
или:
http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX : 32002L0058: EN: HTML

Конечно, _многие_ веб-сайты / приложения (_ которые не используют сторонние файлы cookie для отслеживания_) подпадают под действие ‘strictly necessary for the delivery of a service requested by the user’ ..., поэтому мы _используем_ файлы cookie в наших _ прогрессивно расширенных_ веб-приложениях. см. https://github.com/dwyl/hapi-auth-jwt2#want -to-sendstore-your-jwt-in-a-cookie

Хранение JWT в _localStorage _> Хотя мы _ согласны_ с тем, что хранение данных / токенов сеанса в localStorage означает, что _требуется JavaScript _ (_ нам это тоже не нравится, мы предпочитаем прогрессивное улучшение , это было сделано для того, чтобы отметить альтернативный вариант ..._). localStorage - это то, как создаются _все _ приложения, созданные с использованием "_Backend-as-a-Service_", потому что BaaS обычно не принимает файлы cookie ... Вы предполагаете, что полмиллиона разработчиков, использующих Google Firebase , делать неправильно_"...? (_это было бы отличное - отдельное - обсуждение ...! _)

Stateless Сессия является _possible_ с JWTs , потому что они имеют встроенный exp варианта (_expiration time_), однако мы _chose / prefer_ _not _ , чтобы сделать наши занятия без гражданства , а не предпочитают хранить идентификатор сессии ( jti ) _внутри_ JWT который просматривается в магазине Redis _после_ проверки JWT. Это означает, что мы можем _invalidate _ сеанс, когда человек выходит из системы или если его устройство украдено, и ему нужно отозвать активный сеанс.

Да, _первоначальная_ цель JWT - это pass claims between parties in web application environment , именно для этого мы их и используем.

Наши идентификаторы сеансов или токены _ могли_ быть просто случайной строкой, которая проверяется на стороне сервера, но мы _ решили_ использовать JWT для _форматирования_ и _знака_ данных сеанса.

Заключение: давайте обновим ридми, чтобы прояснить_ вещи. 👍

Вместо того, чтобы разделять поднятые вопросы на набор вопросов, как предлагает @nelsonic, я склонен согласиться с тем, что намерение и цели реализации должны быть разъяснены в рамках README. Я не рассматриваю вопросы @ joepie91 как критику использования JWT в контексте веб-приложений как таковых или поддержку файлов cookie как более совершенную; скорее я воспринимаю критику как то, что описание JWT представлено таким образом, который преувеличивает или искажает причину выбора JWT.
То же беспокойство выражено и в # 55 (поясните, что JWT не является шифрованием ...)

Для меня достаточно иметь возможность управлять Firebase и моими собственными сервисами, используя общую заявку, срок действия которой истекает. Я могу расширить его, чтобы в некоторых случаях включать какое-то состояние, а в других - нет, и по-прежнему предпочитаю подход с использованием файлов cookie или более старые подходы к HTTP-аутентификации с контролем доступа.
Мне нравится, что я могу использовать токены JWT как часть более сложного подхода, но я все же согласен с тем, что акцент на преимуществах README должен быть сосредоточен на проблемах, которые мы стремимся решить с их помощью, а не отходить на менее прочную основу. Возможно, большая часть справочного материала в README может быть отнесена к заметкам или даже к Wiki в качестве материала для обсуждения?

Я не знаю, обязательно ли я скажу, что README опасен - кажется немного сильным

Файлы cookie> в Директиве EU ePrivacy Recital 25 файлы cookie прямо упоминаются 5 раз:

Извинения, кажется, я сформулировал это довольно расплывчато. Хотя текст действительно содержит слово «cookie» в нескольких местах, он не определяет его как конкретную концепцию, которая должна быть законодательно закреплена; скорее, он предоставлен в качестве примера (и, таким образом, остальная часть моей точки зрения остается применимой, и «отказ от использования файлов cookie» не устранит волшебным образом необходимость в согласии).

localStorage - это то, как создаются все приложения, созданные с использованием «Backend-as-a-Service», потому что BaaS обычно не принимает файлы cookie ...

Это неактуально и проблема тех сервисов. Это _не_ оправдывает использование JWT для сеансов в вашем собственном приложении.

Вы предполагаете, что полмиллиона разработчиков, использующих Google Firebase, делают это «неправильно» ...?

Помимо того факта, что Firebase очень плохо спроектирована, это обращение к авторитетным источникам и не имеет места в техническом обсуждении. Мне не интересно обсуждать решения конкретной компании по конкретному продукту; Меня интересует только обсуждение достоинств и недостатков данного подхода.

Сеансы без сохранения состояния возможны с JWT, потому что они имеют встроенную опцию exp (время истечения), однако мы выбрали / предпочитаем не делать наши сеансы без состояния, вместо этого предпочитая хранить идентификатор сеанса (jti) внутри JWT, который просматривается в Redis store после проверки JWT. Это означает, что мы можем аннулировать сеанс, когда человек выходит из системы или если его устройство украдено, и ему необходимо отозвать активный сеанс.

В этот момент от использования JWT больше нет реальной пользы. Почему вы просто не используете express-session или какое-нибудь другое проверенное и рецензируемое решение для сессий, которое подходит к вашему стеку? Рекомендация для JWT здесь не имеет смысла, потому что люди _не должны запускать собственное управление сеансами в первую очередь_.

Не говоря уже о том, что истечение срока сеанса должно обрабатываться на стороне сервера, поэтому exp в вашем JWT по существу бесполезны.

Да, основная цель JWT - передавать претензии между сторонами в среде веб-приложений, именно для этого мы их используем.

JWT ни в малейшей степени не связаны с «средами веб-приложений».

Наши идентификаторы сеансов или токены могут быть просто случайной строкой, которая проверяется на стороне сервера, но мы решили использовать JWT для форматирования и подписи данных сеанса.

Опять же, просто используйте для своего стека проверенную реализацию сеанса. JWT - неправильная рекомендация здесь.

Мы со всем уважением не согласны с тем, что содержание этих заметок является «опасным».

Вы можете не соглашаться, но это так. Существует так много способов неправильно использовать JWT - некоторые из которых упоминаются в README в этом репозитории, - что люди вынуждены стрелять себе в ногу. Да вредно.

@ pscott-au: joepie91 - вы явно хорошо разбираетесь в проблемах ... не могли бы вы поделиться некоторыми мыслями о реальных преимуществах такого использования JWT?

Нет никаких преимуществ в использовании JWT для стандартных веб-приложений, если вы не работаете в масштабе Reddit. Некоторые распространенные примеры случаев, когда JWT _ полезны:

• Механизмы единого входа (где JWT используется как одноразовый токен аутентификации, который пользователь обменивает для сеанса в целевом приложении),
• Токены временного доступа для частных изображений, URL-адреса которых предназначены для совместного использования,
• Практически любой сценарий, когда две системы, которые доверяют друг другу, должны обмениваться небольшими объемами данных через ненадежную сторону, без прямого контакта друг с другом или совместного использования серверной части.

Для стандартных сеансов веб-приложений вы должны просто использовать хорошо протестированную реализацию сеанса для любого используемого стека (например, express-session при использовании Express).

Это здорово, потому что это действительно бросает вызов моему опыту. Возможно, какой-то контекст для моего личного интереса к использованию JWT (помимо того факта, что я использую Firebase, что мне было бы интересно узнать о плохих инженерных проблемах, которые я изучу). При создании мобильных приложений / SPA и, в частности, при использовании сервисов, получаемых с нескольких серверов / доменов, я обнаружил, что мне часто требуется возможность единого входа в систему, которую JWT, похоже, хорошо поддается. Насколько я понимаю, использование файлов cookie сеанса развивалось в течение периода, когда безопасность была усилена в браузере и пространстве JS, а внедрение CORS эволюционировало для обработки исключений из этого, оставив нас с довольно хакерским решением, которое JWT каким-то образом решает. .
В течение многих лет подходы к сеансу cookie, безусловно, обеспечивали гораздо лучший подход, чем исходный базовый и дайджест http-аутентификация, и много раз я использовал решение для управления сеансом cookie для веб-приложения.
Но ... я считаю, что большинство приложений, которые я сейчас создаю, являются мобильными или SPA и интенсивно используют REST APIS. Мне нравится иметь возможность легко тестировать с помощью простых запросов curl, не связывая файлы для обработки файлов cookie и не имея дело с несколькими запросами для установления сеанса. Поэтому я обнаружил, что быстро внедряемые API-интерфейсы просто работают, когда я использую JWT. На мой взгляд, для длительных сессий более уместно использовать JWT, чем файлы cookie, хотя я буду размышлять над этим, поскольку это может быть скорее ленью, чем хорошей интуицией. Я могу расширить безопасность в соответствии с OAUTH, если это необходимо, и я хочу защитить вещи более тщательно, но чаще всего сеанс не является чем-то, что я считаю нуждающимся в таком уровне безопасности. Для меня важна гибкость подхода аутентификации на основе JWT в отношении архитектурных изменений в будущем. Я обнаружил, что старый код был переработан, чтобы предоставить JWT auth в качестве опции, и это внесло удивительно небольшую сложность обслуживания, но в большинстве случаев упростило будущую разработку, и я не считаю, что какая-либо его часть по своей сути уступает сеансам cookie.
На самом деле есть преимущества в использовании функций тайм-аута JWT, особенно на мобильных устройствах, и некоторые вспомогательные библиотеки используют это. Например, вы можете настроить приложение для выхода пользователя из системы или оставить его в системе на основании этого тайм-аута, когда устройство не подключено к сети.
На мой взгляд, я не вижу каких-либо убедительных аргументов в пользу масштабных преимуществ JWT по сравнению с сеансовыми cookie-файлами.
Я вижу, как люди предполагают, что JWT можно использовать в качестве файла cookie сеанса, который для меня приносит больше вреда, чем пользы, поскольку файлы cookie имеют собственный период ожидания (не полностью управляемая сторона сервера), и их объединение может сбить с толку.
Многие современные JS-фреймворки обеспечивают большую поддержку JWT, чем файлов cookie, что говорит о том, что протестированное в бою рецензируемое решение для стека на самом деле может иметь тенденцию к JWT для многих приложений. Хотя популярность JWT для веб-сервисов не является техническим аргументом, отклонить это как несущественное, потому что все они таковы, в равной степени ошибочно. Express не является основным элементом стека, используемого группой dwyl, насколько я могу судить, поэтому нет причин для согласования с ним.
Я надеюсь, что есть какая-то часть моих намерений, с которой вы можете согласиться, поскольку я по-прежнему обеспокоен, но не полностью убежден вашими аргументами.
Я согласен с тем, что README нуждается в серьезном пересмотре и что есть строки, которые он преследует, которые лучше удалить или отодвинуть обратно в текст фонового обсуждения, а не в основной README.

(помимо того факта, что я использую Firebase, что мне было бы интересно узнать о плохих инженерных проблемах, которые я изучу)

Некоторые из проблем заключаются в том, что его клиентская библиотека JS имеет закрытый исходный код и запутана с довольно бесполезным выводом ошибок, нет такой вещи, как «массивы», в клиентской библиотеке есть много странных ошибок, из-за которых вы можете просто не получить ответ на по неясным причинам, система ACL использует нестандартный вариант JSON, который не поддерживает даже их собственный редактор, JS API требует использования API псевдособытий, а не обычного API обратного вызова (но не ведет себя согласованно), и скоро.

При создании мобильных приложений / SPA и, в частности, при использовании сервисов, получаемых с нескольких серверов / доменов, я обнаружил, что мне часто требуется возможность единого входа в систему, которую JWT, похоже, хорошо поддается. Насколько я понимаю, использование файлов cookie сеанса развивалось в течение периода, когда безопасность была усилена в браузере и пространстве JS, а внедрение CORS эволюционировало для обработки исключений из этого, оставив нас с довольно хакерским решением, которое JWT каким-то образом решает. .

Не совсем точно. Ваше приложение и сторонние API - это разные вещи с разными требованиями к аутентификации. В то время как система аутентификации на основе токенов может иметь смысл в приложении при взаимодействии со сторонним API, это не имеет смысла для вашего собственного приложения, даже если это SPA. Это также не связано с «единым входом», который относится к нескольким службам конечных пользователей, использующим одну и ту же службу входа.

CORS - это отдельная проблема, не имеющая отношения к этому.

Но ... я считаю, что большинство приложений, которые я сейчас создаю, являются мобильными или SPA и интенсивно используют REST APIS. Мне нравится иметь возможность легко тестировать с помощью простых запросов curl, не связывая файлы для обработки файлов cookie и не имея дело с несколькими запросами для установления сеанса. Поэтому я обнаружил, что быстро внедряемые API-интерфейсы просто работают, когда я использую JWT.

В процессе разработки у вас могут быть определенные требования к тестированию, но они не должны влиять на подход, который вы применяете в производственной среде. Помимо того факта, что большинство вещей, которые являются SPA, на самом деле не должны быть SPA с самого начала (SPA предназначены для веб-приложений, а не для веб-сайтов!), Нет никаких причин, по которым вы не можете использовать сеансы с ними.

Помимо этого, cURL отлично поддерживает файлы cookie, и есть много других, более совершенных клиентов для тестирования API, таких как httpie или даже http-prompt .

Я могу расширить безопасность в соответствии с OAUTH, если это необходимо, и я хочу защитить вещи более тщательно, но чаще всего сеанс не является чем-то, что я считаю нуждающимся в таком уровне безопасности.

Сессия - один из самых важных аспектов вашего приложения. Если он недостаточно безопасен, ваше приложение по сути сломано и полностью уязвимо. Вот почему, например. хранить JWT в LocalStorage - ужасная идея.

Для меня важна гибкость подхода аутентификации на основе JWT в отношении архитектурных изменений в будущем. Я обнаружил, что старый код был переработан, чтобы предоставить JWT auth в качестве опции, и это внесло удивительно небольшую сложность обслуживания, но в большинстве случаев упростило будущую разработку, и я не считаю, что какая-либо его часть по своей сути уступает сеансам cookie.

Здесь не вводится гибкость, которая когда-либо понадобится 99,99% разработчиков, и я уже выделил некоторые из проблем, которые она вызывает, например, устаревшие данные и невозможность аннулировать токены.

На самом деле есть преимущества в использовании функций тайм-аута JWT, особенно на мобильных устройствах, и некоторые вспомогательные библиотеки используют это. Например, вы можете настроить приложение для выхода пользователя из системы или оставить его в системе на основании этого тайм-аута, когда устройство не подключено к сети.

Это не уникально для JWT; вы можете сделать это с помощью сеансов на стороне сервера. Фактически, JWT не могут быть признаны недействительными без введения (сложной) архитектуры с отслеживанием состояния, поэтому здесь действительно выигрывают сеансы.

На мой взгляд, я не вижу каких-либо убедительных аргументов в пользу масштабных преимуществ JWT по сравнению с сеансовыми cookie-файлами.

Преимущество масштабирования заключается в том, что вам не нужен один канонический сервер, содержащий все сеансы (поскольку данные могут храниться непосредственно в токене), что означает, что вы можете устранить узкое место. Но, как я уже сказал, практически ни один разработчик не столкнется с этой проблемой на практике. Это полезно только для очень крупных проектов.

Многие современные JS-фреймворки обеспечивают большую поддержку JWT, чем файлов cookie, что говорит о том, что протестированное в бою рецензируемое решение для стека на самом деле может иметь тенденцию к JWT для многих приложений.

Мне еще предстоит увидеть фреймворк, который не поддерживает файлы cookie сеанса.

Express не является основным элементом стека, используемого группой dwyl, насколько я могу судить, поэтому нет причин для согласования с ним.

Это их проблема. Express был просто одним из примеров, хорошо протестированные реализации сеансов существуют практически для каждой часто используемой среды.

Суть в том, что для любого разработчика, читающего этот репозиторий, не будет никаких реальных преимуществ JWT и несколько недостатков или даже проблем с безопасностью. Это просто не разумный технический выбор или рекомендация, и это действительно конец.

@ joepie91 Я не могу передать вам, насколько я _ рад_, что вы нашли наше репо / заметки и потратили свое время, чтобы прочитать их и дать нам обратную связь! Серьезно, если я когда-нибудь встречусь с тобой лично, я дам тебе поддон того, что ты хочешь выпить! 🍺

Если я сделаю вас участником этого репо, вы просмотрите мой запрос на слияние для его _улучшения_? 📝

Кроме того, @AshleyPinner , @alfiepates , @ sunny-g, как вы, господа, наткнулись на эту _частную_ дискуссию? была ли проблема опубликована на Redit / Hackernews? (_Мне интересно, как люди находят наши сообщения ..._)

Я пережевал это в течение нескольких дней и просто не могу согласиться со многими аргументами против использования JWT в качестве выбора по умолчанию перед традиционными сеансовыми cookie-файлами в современных SPA и мобильных приложениях.
Я думал о построении матрицы решений, чтобы взвесить плюсы и минусы подходов cookie / аутентификации JWT для конкретных требований или детализировать плюсы и минусы для набора вариантов использования, прежде чем думать о переписывании README. Мне кажется, что многие из реальных проблем, с которыми люди сталкиваются при создании сложных приложений, по большей части решаются менее элегантно или, по крайней мере, столь же проблематичны при использовании сеансов cookie. Плакат с проблемой создает впечатление, что JWT - это некоторая взломанная вместе ненадежная незрелая технология, которая не подходит для современных приложений, и это утверждение, возможно, даже более опасно, чем предоставление полностью проработанного примера ее использования для аутентификации пользователя.
Я нашел эту статью OATH полезной . Я думаю, что одна из вещей, которая вызвала такую ​​сильную реакцию на это репо, но автор сообщения о проблеме, - это обсуждение функций, которые обычно ожидаются в сеансах cookie с использованием JWT, которые умаляют некоторые из основных преимуществ JWT, в первую очередь связанных с тем, что он может быть без гражданства. Вводя состояние за счет включения постоянного хранилища, мы исключаем один из основных вариантов использования JWT и повторно внедряем вещи, которые являются зрелыми с использованием файлов cookie.
Тем не менее, сложные приложения склонны требовать некоторого нахождения состояния - даже если только для транзакционных запросов для действий, которые обрабатываются за пределами срока действия одного HTTP-запроса. Это не должно препятствовать использованию JWT, но должно дать нам паузу, чтобы подумать, какую роль JWT играет в транзакции. Я считаю нормальным иметь JWT, который предоставляет доступ к ресурсу, и у ресурса есть состояние для пользователя, которое запрещает доступ к службе; в этом случае необходимо просрочить не JWT, а состояние пользователя, обращающегося к службе с помощью JWT.

Дальнейшее расширение использования файлов cookie в качестве транспортного механизма устраняет еще одно преимущество и возвращает нас к использованию файлов cookie, но игнорирует обычные функции библиотеки и переписывает функции с нуля, что вносит дополнительную неоднозначность, так как мы получаем дублирующиеся тайм-ауты и т. Д. Когда я упоминал CORS ранее возможно, было бы лучше четко указать на трудности использования нескольких доменов с файлами cookie. Конечно, вы можете установить домены с подстановочными знаками, но если они существенно различаются, традиционные файлы cookie сеанса быстро становятся громоздкими. Можно утверждать, что большинству разработчиков не нужен аутентифицированный клиент для доступа к защищенным ресурсам в нескольких доменах, но это становится гораздо более распространенной практикой, чем экзотическим пограничным случаем.
В некотором смысле, как новый человек, начинающий изучать управление аутентифицированными сеансами, я понимаю, что это может быть неподходящим способом узнать о том, как ограничить доступ к ресурсу в веб-приложении для аутентифицированных пользователей в простейшем смысле, но использование JWT станет более заметным в качестве отправной точки для аутентифицированных сеансов, поэтому отклонить это, потому что мы использовали файлы cookie сеанса в течение длительного времени, недостаточно, чтобы я мог поверить, что все должны начинать с файлов cookie сеанса и только узнавать и использовать JWT. когда они обнаруживают, что не могут обмениваться файлами cookie между доменами или нуждаются в доступе к стороннему API или должны иметь возможность определять срок действия без проверки сервера, или ставят под сомнение хранение учетных данных пользователя для входа на мобильное устройство и т. д. и т. д. .

Неправильно преуменьшать преимущества токенов без сохранения состояния как чего-то, что не имеет значения, если только вы не используете сайт верхнего уровня. Даже когда мы заморачиваемся, вводя новый уровень состояния, отделение сеанса от сервера имеет множество преимуществ.

@nelsonic Если посмотреть на 4744cd1bb8991bc4057c749f86007fcecac19d1d, это кажется более четкой формулировкой. Однако заголовок , похоже, не отражает изменений.

@ pscott-au: в современных SPA и мобильных приложениях.

Это _ полностью_ ортогонально вашему выбору механизма сеанса. Не говоря уже о том, что большинства вещей, которые сегодня являются СПА, быть не должно. Использование SPA для веб-сайта (в отличие от веб-приложения) ломает Интернет.

Мне кажется, что многие из реальных проблем, с которыми люди сталкиваются при создании сложных приложений, по большей части решаются менее элегантно или, по крайней мере, столь же проблематичны при использовании сеансов cookie.

Такие как?

Плакат с проблемой создает впечатление, что JWT - это некоторая взломанная ненадежная незрелая технология, которая не подходит для современных приложений.

Нет, это не так. JWT как технология не ужасна (даже если в спецификации есть некоторые сомнительные решения) - сеансы просто не являются его предполагаемой целью, и они плохо подходят для этого варианта использования.

Я не говорю, что инструмент плохой, я говорю, что вы его неправильно используете.

и это утверждение, пожалуй, даже опаснее, чем

Каково ваше обоснование этого?

Я нашел эту статью OATH полезной.

По пунктам:

• Без сохранения состояния, масштабируемость и развязка: я уже признал, что это теоретическое преимущество, но на практике оно практически никому не нужно. Вы также должны учитывать, что Auth0 имеет здесь личную заинтересованность, которая _не_ приносит пользу вам как разработчику: _ "Сторонние службы, такие как Auth0, могут обрабатывать выпуск токенов, а затем серверу нужно только проверить действительность токена. "_ Аутсорсинг вашей аутентификации, кстати, _ ужасная_ идея.
• Кросс-домен и CORS: полная чушь. Здесь говорится о _storage method_, который полностью не зависит от того, содержит ли токен _ данные сеанса или нет. Вы можете отправить идентификатор сеанса вручную или сохранить JWT в файле cookie. Не имеет ничего общего с JWT и сеансами - что также свидетельствует о предвзятости / незнании автора статьи, поскольку сравнение «куки / токены» _ не имеет никакого смысла для начала_. Он также полностью игнорирует эту проблему безопасности .
• Хранить данные в JWT: не функция. То же относится и к сеансам. И, кстати, печенье.
• Производительность: это просто повторение точки «без сохранения состояния», в основном - помимо того факта, что _ вообще_ не ясно, может ли криптографическая проверка обязательно превзойти что-то вроде Redis по производительности обработки данных сеанса (их сравнение с СУБД нереально) , это также совершенно незначительная оптимизация производительности практически для каждого веб-приложения. Это называется «преждевременной оптимизацией», и ее часто не рекомендуют по очень веским причинам.
• Мобильная версия: ерунда. Если ваша библиотека HTTP не поддерживает файлы cookie, _поискните лучшую библиотеку HTTP_. Файлы cookie поддерживаются отлично, это просто заголовки HTTP.

Так что нет, эта статья не содержит каких-либо новых преимуществ JWT, о которых я еще не рассказывал. Он просто искажает полезность (отсутствие состояния) как нечто, что применимо к каждому приложению (а это не так), а затем делает бессмысленные сравнения и переоценивает производительность сеанса в остальном.

Я думаю, что одна из вещей, которая вызвала такую ​​сильную реакцию на это репо, но автор сообщения о проблеме, - это обсуждение функций, которые обычно ожидаются в сеансах cookie с использованием JWT, которые умаляют некоторые из основных преимуществ JWT, в первую очередь связанных с тем, что он может быть без гражданства.

Как я уже сказал, на практике это почти никогда не приносит пользы. Вы можете повторять один и тот же момент безгражданства снова и снова, но это не сделает его более действительным или применимым. Это абсолютно не универсальное требование.

Я считаю нормальным иметь JWT, который предоставляет доступ к ресурсу, и у ресурса есть состояние для пользователя, которое запрещает доступ к службе; в этом случае необходимо просрочить не JWT, а состояние пользователя, обращающегося к службе с помощью JWT.

В этом случае у вас нет никаких преимуществ перед обычным идентификатором сеанса.

[...] Когда я упоминал CORS ранее, возможно, было лучше прямо указать на трудности использования нескольких доменов с файлами cookie. Конечно, вы можете установить домены с подстановочными знаками, но если они существенно различаются, традиционные файлы cookie сеанса быстро становятся громоздкими.

Это также полностью ортогонально точке. Речь идет исключительно о том, где вы _ храните_ свои идентификаторы, а не о том, содержат ли они сами данные сеанса. И снова угроза безопасности .

но использование JWT только станет более заметным в качестве отправной точки для аутентифицированных сеансов.

И это меня очень беспокоит, потому что такое видное использование основано на незнании и шумихе и сопряжено с множеством проблем с безопасностью. Это серьезный шаг назад.

так что отклонить это, потому что мы использовали файлы cookie сеанса в течение длительного времени

Я никогда ничего подобного не говорил. Я привел несколько очень ясных причин того, почему JWT объективно уступает_ в управлении сеансами.

и узнают и используют JWT только тогда, когда обнаруживают, что не могут совместно использовать файлы cookie между доменами.

В таком случае проблема с безопасностью . Файлы cookie _ не являются обязательными_.

или вам нужен доступ к стороннему API

Не имеет отношения к сеансам.

или нужно иметь возможность определять срок действия без проверки сервера

Невозможно, потому что серверу необходимо сохранить возможность явно аннулировать сеанс, например. когда пользователь меняет свой пароль или принудительно закрывает другие сеансы.

или сомневаться в хранении учетных данных пользователя на мобильном устройстве и т. д. и т. д.

Печенье. Выполнено.

Неправильно преуменьшать преимущества токенов без сохранения состояния как чего-то, что не имеет значения, если только вы не используете сайт верхнего уровня. Даже когда мы заморачиваемся, вводя новый уровень состояния, отделение сеанса от сервера имеет множество преимуществ.

Однако вы не упомянули ни одного из них, к которым я еще не обращался и не учел в своих выводах. Мне очень жаль, но вы защищаете новаторские подходы ради новизны и полностью игнорируете _объективные, технические свойства_ различных подходов.

Это то, что называется «шумихой», и это крайне вредно.

Без сохранения состояния: важно, когда приложение должно работать в автономном режиме и сохранять какое-то значение.

Автономные приложения не нуждаются в аутентификации _ вообще_. По определению нет взаимодействия с другими системами.

Междоменная аутентификация учетных данных: важно, если вы разделяете свое приложение на микросервисы с использованием нескольких серверов.

Верный. Но в этом случае вы не используете JWT _ в качестве механизма сеанса_, вы используете его как одноразовый токен, который можно _обменивать_ для сеанса. Между ними есть очень большая разница и компромиссы, которые они представляют.

( РЕДАКТИРОВАТЬ: конечно, это предполагает _stateful_ микросервисы, и с 'stateful' я _не_ ссылаюсь на сеанс, а на сам сервис. Для микросервисов, которые выполняют задачи без сохранения состояния, достаточно одноразовых токенов _без_ использования сеанса вообще, с одноразовыми токенами, выпускаемыми сервером приложений. Для серверов приложений, взаимодействующих с микросервисами, также подойдет JWT - здесь нет понятия «сеанс», и отозвать токен можно, изменив ключ подписи.)

Вы можете продолжать отрицать полезность JWT

Опять же, я ничего подобного не делаю. Это целиком и полностью ваши слова.

Когда я пытаюсь предоставить более подробную информацию, вы просто отклоняете мои дела как не относящиеся к делу или плохую практику ... на мой взгляд, это неправильно.

Тогда я ожидаю, что вы уточните, почему это неправильно, а не просто скажете «это неправильно!» и ожидайте, что я приму это за чистую монету. Я конкретно обращаюсь к каждому пункту, который вы говорите, именно по этой причине.

Использование cookie для управления сеансом входа в систему iOS по умолчанию - не лучшее решение.

Почему?

файлы cookie могут использоваться не по назначению

Это пустое заявление. Неправильное использование _how_? И как это не относится к значениям, хранящимся в локальном хранилище? И какое это вообще имеет отношение к JWT, учитывая, что «куки» - это метод хранения, а не механизм сеанса? Сравнение «JWT и куки» - это сравнение яблок и апельсинов, это даже не один и тот же класс вещей!

Использование JWT для управления сеансами отличается и имеет другие свойства, чем сеансы cookie - это не делает его хуже, а просто имеет другие критерии рабочих параметров при разработке подходящего решения. Если вы хотите использовать файлы cookie, используйте файлы cookie - если они соответствуют вашим требованиям, используйте их - почему вы хотите, чтобы другие люди не рассматривали какой-либо другой подход?

Я не. Я очень четко указал исключения, когда JWT является правильным решением. Я также _ очень четко_ указал, что JWT не подходит в качестве механизма сеанса общего назначения . Перестань вкладывать слова мне в рот.

Вы считаете, что сеансы входа в систему имеют ценность только для аутентификации на вашем веб-сервере с постоянным хранилищем, игнорируя тот факт, что я вполне могу захотеть, чтобы некоторые службы данных предоставлялись альтернативными поставщиками, которые проверяют тот же JWT и не требуют создания новых файлов cookie. . Каким образом это не имеет отношения к сеансам ???

Потому что нет причин, по которым вы не можете использовать как JWT, так и сеансы для разных целей. Попытка втиснуть все это в единый механизм ради этого _ полностью_ ошибочна. Используйте подходящий инструмент - «не требовать создания новых файлов cookie» - это совершенно произвольный показатель и, в действительности, не та выгода, на которую вы рассчитываете.

Если вы видите проблемы с безопасностью, определите их и пометьте их - они могут не помешать шоу, но могут быть полезны при принятии решения. Ваша язвительная формулировка не признает этого и даже не рассматривает такую ​​возможность, потому что вы продолжаете заявлять, что файлы cookie сеанса должны использоваться для каждого приложения http, что просто смешно.

Опять таки. Нет. Я сказал. Перестань вкладывать слова мне в рот.

Приведенные вами примеры роли сеансов для обеспечения соблюдения определенных правил, таких как завершение работы при изменении пароля или для управления ограничениями служб, не являются встроенной функцией файлов cookie сеанса, а просто функцией, которая обычно используется при таком подходе.

Это функция, которая архитектурно _ требует_ сеансов с отслеживанием состояния. Я не утверждаю, что это обеспечивается сеансовыми cookie-файлами - я утверждаю, что это _ невозможно_ с токенами без сохранения состояния.

Если ваше решение достаточно удобно для предоставления аутентифицированного доступа без проверки базы данных для доступа к ресурсу в течение всего сеанса, то почему вы настаиваете на том, что это провал этого подхода.

Опять же, не то ,

Когда мы предлагаем, чтобы определенные элементы управления (если они требовали какого-либо сеанса с возможностью завершения) могли быть введены по мере необходимости, вы отвечаете, что файлы cookie имеют это встроенное, и вам никогда не следует пытаться использовать другие подходы. Реализация этого вида управления не требует таких значительных накладных расходов, чтобы исключить сеансы аутентификации JWT через файлы cookie.

Дело не в накладных расходах. Дело в том, чтобы использовать проверенные и проверенные решения, которые, как известно, хорошо работают . Пополнение собственной безопасности - ужасная идея в _ любой_ ситуации, в том числе и в этой.

Вы игнорируете количество запросов на файлы cookie и предполагаете, что единственное соображение производительности - это поиск. Необходимость координировать обновления и т. Д. И зависеть от ... о, неважно ... (сдался здесь)

О чем ты вообще говоришь? «Обновления» файлов cookie обрабатываются встроенными в HTTP-ответы путем отправки нового файла cookie - здесь нет ничего лишнего, кроме обновления хранилища сеансов, которое я уже рассмотрел в моем примере Redis. Если вы думаете, что есть другие соображения по поводу производительности, _ перечислите их_.

Вам может понравиться, что файлы cookie ограничены доменами, и вы считаете, что разрешение их использования в нескольких доменах создает проблемы безопасности, которые препятствуют их использованию - это нормально - я нет.

Опять же, не то ,

JWT - не следующая вещь, которая заменит все файлы cookie сеанса, но и не такая серьезная мерзость (когда используется для управления сеансами), как вы указываете.

Да, они. Единственная причина, по которой вы когда-либо хотели бы использовать JWT для сеансов, заключается в том, что альтернативы хуже или невозможны, и это чрезвычайно редкий крайний случай.

Вы относитесь к безопасности как к абсолюту, не говоря уже о различных усовершенствованиях, которые могут быть внесены в этот подход, если / когда потребуется, и о том, как сложность этой эволюции сопоставима с традиционными подходами, основанными на сеансах.

Я отношусь к безопасности как к абсолюту только тогда, когда она _is_ абсолютная. Я также рассмотрел возможные способы решения этой проблемы и объяснил, что они не являются хорошим решением по сравнению с сессиями, потому что конечный результат все еще хуже. Если вы думаете, что мне не хватает какого-то дела или решения, упомяните об этом. Прекратите расплывчато называть «другие варианты», даже не объясняя, что это такое. Насколько я могу судить, сейчас вы блефуете.

Это не шумиха - не основанная на незнании, но это действительное решение проблем, с которыми регулярно сталкиваются при создании гибридных приложений, требующих перекрестной аутентификации для служб, которые не стремятся обеспечить абсолютную максимальную безопасность, которую может предложить технология, и по уважительной причине - очень практично - в очень широком смысле принято - не превращает все в дерьмо.

Повторение вашего утверждения не делает его более верным. Я уже разобрали , почему это неверно, и ставя под угрозу безопасность по причинам Hype не является приемлемым.

Для некоторых из нас наличие гибкости для управления сеансом с более высокой степенью детализации, чем обеспечивается с помощью файлов cookie, обеспечивает большую гибкость - если вы не видите варианты использования, тогда все в порядке - я ожидаю, что если вы создадите много гибридных приложений, которые вы будете, и, возможно, тогда вы сможет лучше сформулировать контраргументы по некоторым из представленных вами пунктов, чем я.

Нет "большей гибкости". Опять же, если вы думаете, что есть, объясните, как это сделать.

В любом случае - вы гораздо красноречивее меня и явно непоколебимы в своем положении.

Нет. Я просто ожидаю, что кто-то предоставит веские, хорошо аргументированные, технически правильные аргументы, если они захотят изменить мои взгляды. Вы этого не сделали.

Я помню, как в последний раз у меня была такая безжалостная привязанность к подходу, когда кто-то утверждал, что дайджест-аутентификацию никогда не следует заменять сеансовыми cookie-файлами.

... и это было бы прекрасным примером такой ошибки.

Суть в том, что половина ваших заявлений вкладывает мне в рот слова, которых я никогда не произносил, не подразумевал и не намеревался. Другая половина приводит доводы в пользу ненужного компромисса в сфере безопасности или выдвигает вялые заявления о «других преимуществах» или «других решениях», даже не вдаваясь в подробности.

Честно говоря, я устал от этого - я не думаю, что эта дискуссия пойдет в конструктивном направлении, и это запутывает нить. Единственная причина, по которой я продолжаю отвечать, - это риск того, что люди будут дезинформированы из-за вашего отсутствия аргументов.

Если вы хотите и дальше верить в то, что JWT - это святой Грааль, несмотря на отсутствие технических аргументов в поддержку этой идеи, то это ваш выбор, но вы _не убедите меня_, если не придумаете _ реальных технических аргументов_, и продолжаете повторять те же утверждения снова и снова. и снова никому не поможет.

Подведем итог моим пунктам для тех, кто бегло просмотрел всю дискуссию:

• JWT не предназначен для сеансов, а предназначен для передачи подписанных заявок, обычно одноразовых.
• JWT не подходит для сеансов из-за невозможности аннулировать токены, проблем с устаревшими данными и необходимости писать непроверенные реализации, чтобы заставить его работать. Это вопросы безопасности.
• Сравнение «Cookies и JWT» недопустимо; один - это механизм хранения, а другой - формат токена. Файлы cookie не являются
• Иногда вы _не можете_ использовать сеансы с отслеживанием состояния, потому что вы работаете в очень большом масштабе, и в этих случаях JWT _ может_ быть `` наименее плохим '' вариантом, но эти случаи редки, и если вы не работаете на крупном сайте размером Reddit, вы, скорее всего, никогда с ними не столкнетесь.

(Кстати, Reddit использует сеансы с отслеживанием состояния.)

Я считаю, что цель этого репо - проложить путь для реализации мобильного гибридного SPA, а использование JWT в качестве замены сеансов cookie является распространенным и почти стандартным подходом.
Одним из драйверов этого является проблема, связанная с привязкой файлов cookie к домену, когда SPA может фактически требовать доступа к микросервисам в нескольких доменах на разных платформах. JWT - это аккуратный подход к ограничениям файлов cookie в этом контексте. Использование подхода OAUTH или OAUTH2 было бы более надежным с точки зрения безопасности, но вносит сложность, которая может не требоваться для многих приложений. Сеансы носителя JWT, которые не зависят от согласования токена AUTH, не являются злоупотреблением JWT, а представляют собой применение менее безопасного подхода для упрощения и для приложений, которые могут получить больше от быстрой реализации, чем дополнительная безопасность, обеспечиваемая более надежный подход. В то же время, упрощая быструю реализацию, он обеспечивает более четкий путь перехода к одноразовым токенам, чем другие подходы.
Некоторая негативная реакция и язвительная реакция на использование заголовков токенов-носителей JWT в качестве замены сессионных cookie-файлов действительно основана на том, что некоторые люди представляют их как эволюцию или улучшение файлов cookie в более широком смысле, что, как я согласен, не соответствует действительности. Я прошу вас принять во внимание мои варианты использования и то, как вы подойдете к ним с помощью файлов cookie.
использование JWT для управления сеансом аутентификации должно выполняться с осторожностью, а недостатки должны быть явными, однако отклонение их как бесполезной шумихи, всегда используемой вне контекста, вводит в заблуждение и неверно.
Использование JWT означает, что вам не нужно обновлять файлы cookie каждый раз, когда клиент связывается с сервером. Разумная уверенность может быть обеспечена без проверки базы данных, хотя эту проверку так же легко расширить, как и с помощью сеансовых файлов cookie.
Использование JWT означает, что клиенты с заблокированными файлами cookie не будут вынуждены возвращаться к использованию скрытых переменных сообщений и т. Д. В качестве засыпки.
Использование JWT в нескольких службах позволяет службе, не требующей аутентификации, но требующей некоторого указания на достоверность простого поля данных, такого как uid, которое можно обернуть в JWT и передать.
Подходы JWT поддаются более сложным подходам OAUTH.
Запросы JWT REST могут выполняться без отправки учетных данных или запроса файла cookie перед доступом к службе, что может упростить реализацию REST / SPA.
Использование заголовка-носителя или заголовка cookie не сильно отличается, когда дело доходит до безопасности (за исключением ограничений домена, которые действительно могут быть нежелательными. (NB, я не вкладываю слова вам в рот, а пытаюсь интерпретировать то, о чем вы говорите, говоря, что безопасность хуже)
Если продолжительные периоды отсутствия являются обычными / ожидаемыми, например, в мобильных приложениях, файлы cookie могут быть менее желательными, чем подход JWT. Наличие более четкого пути к самостоятельной проверке учетных данных может облегчить поведение без проверки на сервере.
Если вы согласны с тем, что существуют варианты использования сеансов, которые могут иметь длительные периоды автономного режима, тогда сеансы не обязательно сохраняют состояние.
Если вы можете согласиться с тем, что сеансы могут успешно существовать с несколькими состояниями с точки зрения клиента и сервера, то, возможно, вы можете приблизиться к вариантам использования, которые включают периоды длительного отсутствия подключения к серверу (например, сбор пользовательских данных для пакетного обновления при повторном подключении). Бывают случаи, когда клиент может работать более эффективно, зная, что срок сеанса истек и требуется обновление без управления другим уровнем данных. Также возможность использовать JWT в качестве проверки сеанса даже после изменения пароля и т. Д. Может быть полезна в некоторых случаях, чтобы разрешить передачу данных на уровень бизнес-логики и решить, как принять запрос.
Вы все время говорите мне, что файлы cookie безопасны, что, как я предполагаю, относится к реализации в браузерах и т. Д. - вне браузера я не понимаю, почему они по своей сути более безопасны - возможно, вы можете уточнить?
В приложениях SPA / Hybrid зависимость от файлов cookie не обязательно является единственной исходной позицией - полагаясь на обработку файлов cookie браузером, вы не приближаетесь к нативному, но вводит зависимость от UIWebView или чего-то еще, и я не уверен, что это всегда будет веди себя так, как я ожидал.
Токены могут храниться в памяти в течение всего времени выполнения приложения без необходимости сохранения - это не совсем то же самое, что полагаться на целостность файлов cookie - в iOS есть более детальный контроль, по крайней мере, в разрешениях на хранение, которые существуют за пределами браузера. и это кажется мне более подходящим, чем привязка к хранилищу в браузере.
Файлы cookie действительно являются необязательными - нет закона, согласно которому вы должны использовать только файлы cookie.
Отделение сеанса от сервера может в некоторых случаях быть плохим, но не всегда - современные подходы, включая использование JWT, создают новые проблемы, но также и новую гибкость, и эта гибкость включает не только наименее плохие подходы.

Подводя итог моей позиции:
Использование JWT как части решения для сеанса аутентификации не всегда превосходит файлы cookie сеанса.
JWT подходит для сеанса, если вы знаете о преимуществах и имеете основание не требовать упрощенного признания недействительности.
Файлы cookie - не единственное решение.
Большой масштаб - не единственный вариант использования сеанса без сохранения состояния - использование заголовков JWT для аутентификации между доменами / службами является веской причиной их использования в качестве альтернативы файлам cookie сеанса.

Я прошу вас принять во внимание мои варианты использования и то, как вы подойдете к ним с помощью файлов cookie.

Конечно.

Использование JWT означает, что вам не нужно обновлять файлы cookie каждый раз, когда клиент связывается с сервером.

То же самое для файлов cookie сеанса, файлов cookie, содержащих JWT, _и_ самих токенов JWT - вам нужно только явно «обновить» их, если срок их действия скоро истечет. Здесь нет никакой разницы.

Использование JWT означает, что клиенты с заблокированными файлами cookie не будут вынуждены возвращаться к использованию скрытых переменных сообщений и т. Д. В качестве засыпки.

Пользователи, которые блокируют файлы cookie, почти наверняка также заблокируют локальное хранилище и другие меры сохранения (точно по той же причине, по которой они блокируют файлы cookie). Расширения конфиденциальности делают то же самое. Опять же, «JWT против файлов cookie» _не правильное сравнение_, и если пользователь блокирует файлы cookie, вы не сможете сохранить токен _в любом случае_. JWT или нет, не имеет значения.

(Если пользователь блокирует файлы cookie оптом, он уже предпочитает не сохранять данные в любом случае, поэтому попытка поддержки аутентификации для пользователей, блокирующих файлы cookie, - это немного потерянное дело. Это компромисс, который приходит с этим, и это полностью технически разумный компромисс.)

Использование JWT в нескольких службах позволяет службе, не требующей аутентификации, но требующей некоторого указания на достоверность простого поля данных, такого как uid, которое можно обернуть в JWT и передать.

См. Редактирование моей предыдущей публикации (третий абзац), в которой рассматриваются одноразовые токены в распределенных архитектурах. Это не сеансы, и они не должны быть постоянными, поэтому проблемы, которые я описал, здесь не применимы.

Подходы JWT поддаются более сложным подходам OAUTH.

OAuth использует одноразовые токены. Это не замена сессиям. Опять же, см. Правку моего предыдущего поста.

Запросы JWT REST могут выполняться без отправки учетных данных или запроса файла cookie перед доступом к службе, что может упростить реализацию REST / SPA.

Они не могут. Вам все равно нужно получить JWT _somehow_, что означает, что он должен быть выпущен сервером, а это означает, что вам нужно запросить его у сервера. Не имеет значения, возвращает ли сервер файл cookie или другой заголовок или значение. И снова, сравнение «куки против JWT» не является корректным.

Использование заголовка носителя или заголовка cookie не сильно отличается, когда дело доходит до безопасности (за исключением ограничений домена, которые действительно могут быть нежелательными.

Не вижу здесь аргументов.

Если продолжительные периоды отсутствия являются обычными / ожидаемыми, например, в мобильных приложениях, файлы cookie могут быть менее желательными, чем подход JWT. Наличие более четкого пути к самостоятельной проверке учетных данных может облегчить поведение без проверки на сервере.

Это не выгода - вам не _ нужен_ токен, пока вы в любом случае не собираетесь связываться с сервером, поэтому вы можете просто попытаться сделать запрос и обработать 403, когда это произойдет. Пытаться не запрашивать у сервера что-то, что по своей сути включает в себя разговор с сервером (а именно, выполнение аутентифицированного запроса), не имеет смысла.

Не говоря уже о том, что если вы хотите заранее узнать, истечет ли срок вашего сеанса, вы можете просто отправить для этого отдельный файл cookie. Поскольку это всего лишь подсказка UX для приложения, вам даже не нужно проверять его подлинность - и вам нужно иметь дело с неожиданными сбоями аутентификации _в любом случае_ из-за сдвига часов и изменения ключей подписи.

В приложениях SPA / Hybrid зависимость от файлов cookie не обязательно является единственной исходной позицией - полагаясь на обработку файлов cookie браузером, вы не приближаетесь к нативному, но вводит зависимость от UIWebView или чего-то еще, и я не уверен, что это всегда будет веди себя так, как я ожидал.

Это не так. Любая разумная HTTP-библиотека - браузер или нет - будет поддерживать файлы cookie. Куки-файлы _ никоим образом_ не являются эксклюзивными для браузеров, они являются функцией HTTP, как и все остальные.

Отделение сеанса от сервера может в некоторых случаях быть плохим, но не всегда - современные подходы, включая использование JWT, создают новые проблемы, но также и новую гибкость, и эта гибкость включает не только наименее плохие подходы.

Я до сих пор не видел конкретных примеров такой «гибкости».

Использование JWT как части решения для сеанса не всегда превосходит файлы cookie сеанса.

Это очень неоднозначное заявление. Вы сравниваете использование JWT в качестве _ части_ решения с использованием файлов cookie сеанса в качестве _ полного_ решения. Это не противоположности - для многих сложных архитектур потребуется комбинация файлов cookie сеанса и одноразовых токенов JWT, например, для систем SSO или распределенных архитектур.

JWT подходит для сеанса, если вы знаете о преимуществах и имеете основание не требовать упрощенного признания недействительности.

Нет. Токены JWT - это «последнее средство», когда вы не можете выполнить требования с помощью файлов cookie сеанса.

Файлы cookie - не единственное решение.

Технически правильно.

Большой масштаб - не единственный вариант использования сеанса без сохранения состояния.

Это _is_ единственный вариант использования, о котором я знаю, и я не видел других подходящих вариантов, упомянутых в этом потоке. Имейте в виду, что я говорю конкретно о _sessions_ без состояния, а не о токенах без состояния _ в целом_.

Я спрашиваю вас: как мне развернуть приложение, которое использует 3 разных сервиса (возможно, в другой контейнерной инфраструктуре и т. Д.), И интегрировать их в приложение, полагаясь на файлы cookie сеанса? Если я настраиваю службу аутентификации и хочу отделить ее от другой службы, это лучший подход для запуска общего обработчика сеанса прокси-файлов cookie? Это крайний случай?
Как файлы cookie обеспечивают мне большую безопасность, гибкость и соответствие стандартам, чем использование длительного JWT для отслеживания моего сеанса. Предполагая, что я не хочу и не забочусь о возможности завершать сеанс по запросу (хотя это не совсем неотъемлемое преимущество файлов cookie, а скорее при обработке запросов), я использую заголовок Bearer с каждым сообщением и отвечаю на сбой с приглашением / сообщением аутентификации для получения сеанса JWT для включения во все заголовки - я могу быть глупым, но просто не понимаю, насколько это менее безопасно? Детали cookie доступны в гибридном приложении так же, как и токен, хотя контроль над постоянством меньше ... Я думаю, я просто не понимаю, почему это такой плохой подход. Конечно, вам нужно предоставить учетные данные для получения JWT, но вы делаете это один раз, а не для каждой службы.

Я спрашиваю вас: как мне развернуть приложение, которое использует 3 разных сервиса (возможно, в другой контейнерной инфраструктуре и т. Д.), И интегрировать их в приложение, полагаясь на файлы cookie сеанса?

Зависит от того, что делают 3 службы. Вы можете уточнить?

Если я настраиваю службу аутентификации и хочу отделить ее от другой службы, это лучший подход для запуска общего обработчика сеанса прокси-файлов cookie? Это крайний случай?

У вас будет служба аутентификации, выдающая одноразовый токен JWT, указывающий на успешную аутентификацию, при необходимости включая «информацию профиля» для пользователя, в зависимости от вашей архитектуры. Затем, в зависимости от приложения:

1. Если обычный веб-сайт: служба аутентификации перенаправляет на страницу аутентификации на сервере приложений, например. передача токена JWT в качестве параметра запроса. Сервер приложений проверяет токен и предоставляет пользователю файл cookie сеанса.
2. Если SPA: служба аутентификации возвращает сгенерированный токен в своем ответе (JSON?). Внешнее приложение выполняет HTTP-запрос к конечной точке аутентификации сервера приложений, включая токен в качестве параметра, и после проверки сервером приложений получает взамен cookie сеанса.
3. Если автономное приложение (настольное или мобильное): как для SPA, но с использованием библиотеки HTTP, которая поддерживает файлы cookie, а не внешнего приложения в браузере.

В обоих случаях токен JWT будет действителен только в течение примерно 5 минут (для учета разброса часов) и будет использоваться один раз - для обмена на сеанс на сервере приложений. Если вы включите информацию профиля в токен, служба аутентификации останется полностью отделенной от приложения.

РЕДАКТИРОВАТЬ: добавлен автономный вариант приложения.

Предположим, мы находимся в сценарии разработки мобильного приложения SPA / Hybrid. Также предположим, что мы просто используем JWT для сеанса, а не OUATH с токенами аутентификации и носителя - просто войдите в систему и получите токен носителя.
Представим, что у нас есть приложение реального времени, в котором каждый сеанс выполняет запросы ко всем 3 сервисам каждые 5-15 секунд. Многие пользователи входят в систему для быстрой проверки статуса или для публикации данных ГИС или чего-то еще, поэтому среднее время использования составляет менее 1 минуты, но они хотят запустить приложение - закрыть его - перезапустить через 3 дня без учетных данных и т. Д. (Добавление деталей, которые здесь в основном не имеют значения, но вещи, которые уберегут меня от куки)

В качестве примера допустим, что я создал сервис AWS с сервисом запросов к графу, картографическим сервисом или сервисом ГИС в докере и интерфейсом REST для postgres db для управления данными профиля пользователя. Я могу использовать один и тот же JWT в запросах заголовков ко всем службам REST и проверять по общему секрету, чтобы иметь общую проверку от JWT, выпущенного один раз.
Предположим, что они сохраняют состояние в своем собственном контексте, но лишь частично в общем контексте.
Это спецификации проблем, которые соответствуют моему предложенному решению с использованием JWT в качестве токена сеанса в качестве токена-носителя и, учитывая аналогичную среду, я спрашиваю, как вы подойдете к использованию файлов cookie сеанса, чтобы мы могли сравнить.

Допустим, все они требуют разумной уверенности в том, что пользователь является тем, кем они себя называют.
Моим решением было бы сгенерировать токен JWT в ответ на сообщение с учетными данными, которое используется во всех службах в заголовке HTTP для аутентификации - при этом проверка выполняется с помощью общего секрета JWT для всех служб.
Служба аутентификации генерирует токен и возвращает его при входе в систему. Маркер включается в заголовок запросов ко всем другим службам в разных доменах. При использовании файлов cookie нам необходимо установить новые файлы cookie для каждого домена. Зачем мне нужно, чтобы службы, делающие новые запросы, проверяли или получали cookie для каждого полученного http, если я могу уверенно полагаться на JWT? Если у меня есть 5 сервисов, мне теперь нужно управлять 5 разными файлами cookie сеанса и обеспечивать координацию между всеми ними. Во многих случаях это может быть правильный подход, но во многих он кажется мне слишком сложным для чего-то, что можно быстро и просто реализовать и не обнаруживает серьезных дыр в безопасности, которые я четко вижу.
Зачем ограничивать временные рамки JWT? Файлы cookie традиционно недолговечны, потому что предполагают регулярный контакт с сервером - что, если я не хочу, чтобы срок их действия быстро истекал, но я рад, что устаревшие сеансы работают долго, потому что я решил, что компромисс с повторной аутентификацией является большим риском.

Если я правильно понимаю вашу ситуацию, у меня за каждый период отправляется 9 запросов, а не 3. У меня встряхивается сервер аутентификации для подтверждения установленных сеансов. У меня больше кода и больше движущихся частей. У меня есть преимущество в том, что я могу завершать сеансы каждый период, но что, если это не является обязательным требованием. Что, если я не забочусь о получении опубликованных данных в течение еще 48 часов после того, как пользователь был удален, и, используя сервер аутентификации для новых запросов, я все еще могу отфильтровать то, что мне не нужно?

В этом случае незначительный временной сдвиг не имеет значения, поскольку гранулярность сеанса установлена ​​должным образом, и, как и в случае с файлами cookie сеанса, я бы реализовал клиент, обновляющий JWT через сервер аутентификации в соответствующий период тайм-аута. Что касается `` профиля '', давайте просто будем использовать общий идентификатор uid в качестве общего идентификатора (если я правильно понимаю), а реализации на стороне сервера содержат общий секрет для подписи / проверки JWT.

В моей предлагаемой архитектуре мне не нужно отзывать токены с более высокой степенью детализации, чем предусмотрено тайм-аутом JWT, так почему я должен вместо этого использовать файлы cookie сеанса?
В предлагаемой мной архитектуре вы можете создавать зависимости между состояниями сервисов, но вы можете спроектировать это, а не зависеть от централизации и необходимости связывать все с авторизацией по умолчанию. Ключевым моментом является гибкость - и это достигается за счет реализации зависимостей, но это на вашем лице с самого начала, а не слой над чем-то, что, хотя и реализовано на всех платформах, обрабатывается по-разному в разных фреймворках. Возможно, нетривиально обновить срок действия cookie для сеанса с использованием узла, php и экзотической обработки сеанса cookie по умолчанию без фактического, поэтому вам может быть предложено просто опубликовать запрос сервера аутентификации напрямую, поэтому мы не только запускаем в 3 раза больше запросов, но у клиента в 3 раза больше запросов.

Если я согласуюсь с вашей предложенной архитектурой, мне действительно нужно бороться с тайм-аутами для нескольких файлов cookie. Например, если клиент входит в систему и получает cookie сеанса авторизации, срок действия которого истекает через 1 час.
а затем через 40 минут они отправляют это значение cookie сеанса в нашу первую службу, которая затем запрашивает сервер аутентификации перед выдачей cookie локального домена, взламываем ли мы внутренний исходный срок действия cookie cookie или устанавливаем тайм-аут для служебного cookie на 20 минут и по истечении этого срока запускает обновление файла cookie аутентификации. Если мне не хватает очевидного решения, это может легко превратиться в большую кучу спагетти, чего можно было бы полностью избежать, используя один JWT с одним ttl, который можно обновить с помощью любой из служб (понимая, как это может расширить токен life) или требуя обновления через сервер аутентификации.

Я мог бы обсудить подходы к устаревшим данным, но объем проблемы в этом варианте использования не зависит от аннулирования устаревших учетных данных (с точки зрения сервера аутентификации), поэтому это не имеет значения.

Насколько я понимаю, мы обсуждаем ваше утверждение о том, что использование JWT в качестве подхода к управлению сеансом с аутентификацией по своей сути является неполноценным и неправильным по сравнению с использованием файлов cookie сеанса в качестве подхода к управлению сеансом с аутентификацией для междоменных служб в гибридном мобильном приложении, которое будет запускаться на устройства периодически без пополнения запаса учетных данных.

Я пытаюсь выяснить, согласны ли вы с тем, что предлагаемый подход по своей сути менее безопасен или менее «правильный» в любом случае. На мой взгляд, простота этой архитектуры дает существенные преимущества и не дает преимуществ более тяжелого и сложного решения, необходимого для управления сеансами по всем сервисам, которые не были учтены и уступили место более простой архитектуре. Если бы вы могли указать, как это решение будет вызывать проблемы, которых не было при использовании файлов cookie для управления сеансами, тогда это действительно помогло бы мне недооценивать их явно (т.е. как скомпрометирована безопасность)

Услуги почти не имеют значения - не уверены, о чем вы имеете в виду?

Есть разница между сервисами с отслеживанием состояния и без отслеживания состояния.

Допустим [...]

Это описание того, как вы решите проблему, а не ее суть. Это бесполезно, когда меня просят объяснить, как подойти к этому с помощью сеансов, потому что он уже предполагает, что вы _не__ использовать сеансы. Вместо этого опишите проблему.

когда я могу уверенно положиться на JWT?

Вы не можете.

Если у меня есть 5 сервисов, мне теперь нужно управлять 5 разными файлами cookie сеанса и обеспечивать координацию между всеми ними.

Вряд ли. См. Мое замечание о сервисах с отслеживанием состояния и без сохранения состояния.

Во многих случаях это может быть правильный подход, но во многих он кажется мне слишком сложным для чего-то, что можно быстро и просто реализовать и не обнаруживает серьезных дыр в безопасности, которые я четко вижу.

Аутентификация и управление сеансами, особенно в распределенных архитектурах, _is_ сложный. Есть причина, по которой в прошлом инженеры по возможности избегали распределенных архитектур. «Просто используйте JWT» приукрашивает это и делает вид, что это проще, чем есть на самом деле, полностью игнорируя устаревание данных и недействительность сеанса.

Дыры в системе безопасности есть, и я предпринял несколько попыток их объяснить - то, что вы не можете четко их видеть, я ничего не могу с этим поделать, если вы не зададите конкретные вопросы о частях, которые вам неясны .

Зачем ограничивать временные рамки JWT?

В приведенном мной примере? Потому что они предназначены как одноразовые токены обмена, а не как постоянные идентификаторы. Вы не хотите, чтобы они были постоянными идентификаторами, потому что вы не можете их отозвать.

Файлы cookie традиционно недолговечны, потому что предполагают регулярный контакт с сервером - что, если я не хочу, чтобы срок их действия быстро истекал, но я рад, что устаревшие сеансы работают долго, потому что я решил, что компромисс с повторной аутентификацией является большим риском.

Нет никакого риска в обновлении сеанса.

игнорировать профиль или перекос часов - детали, которые не имеют большого влияния на наше обсуждение в этой гипотетической версии, поскольку те же проблемы возникают при использовании файлов cookie для аналогичного сценария.

Они так же важны для надежной системы аутентификации, как и все остальные упомянутые моменты. Игнорировать их - не вариант. И опять же, речь идет не о файлах cookie, а о сеансах.

Для сессий нет, те же проблемы _не_ применяются; Централизованное хранилище сеансов с отслеживанием состояния означает, что данные вообще не устаревают, а информацию профиля можно получить в любой момент, а асимметрия часов является проблемой для любых токенов с ограниченным сроком действия, которыми обмениваются разные системы.

Похоже, что мы могли бы резюмировать ваше возражение против JWT, поскольку подход к управлению сеансом может сводиться к тому, что вы прикрепляете к определению сеансов, которое требует отзыва для каждого запроса (и несколько других функций, которые традиционно были частью обеспечения авторизации пользователя. для доступа) и опасность, связанная с их обновлением (если они будут перехвачены). Распределенная обработка - это новая норма - множественные сервисы очень распространены - если мы хотим использовать такой подход к мультисервисной архитектуре, нам нужно полностью понимать последствия. Распределенные базы данных существуют давно. Распределенные хранилища данных, такие как DNS, существуют с самого начала. Иногда простота архитектуры дает больше преимуществ, чем попытка выжать существующий доминирующий стандарт за пределы его проектных ограничений. Если мы знаем о проблемах ACID транзакций в наших сеансах запросов на сервисы, то нет причин, по которым мы не должны использовать подход управления сеансами JWT для аутентификации сервисов, чтобы полностью использовать возможности, не будучи ограниченными тем, что быстро превращается в сложную инфраструктуру, если мы настаиваем. на жестких ограничениях и попробуйте использовать файлы cookie сеанса в качестве лучшего решения.
@ joepie91 - там, где это уместно, вы могли бы использовать аутентификацию сеанса cookie для первичной аутентификации и потребовать это для обновления JWT. Опять же - использование JWT для междоменного доступа к сервису сеанса может использоваться как часть решения, а сеанс cookie также может использоваться, если это необходимо. Дело в том, что JWT как часть управления сеансом - даже для доступа к подмножеству сервисов - я не считаю злым подходом, который не играет никакой роли.
Сеансовые cookie-файлы https также сопряжены с рисками - удивительно, сколько сайтов имеют не установленный флаг ssl и передают cookie в виде открытого текста при обмене данными по SSL. Делает ли это опасными сеансы cookie?
Самый большой риск, который я, кажется, могу обнаружить, заключается в том, что кодировщик позволяет отправить токен на неправильный сервер и что токен фактически позволяет третьей стороне получить доступ к этим вторичным пользовательским ресурсам. Это должно быть отмечено где-то большими красными буквами и возлагает серьезную ответственность на разработчика, чтобы этого не произошло. Разработчик должен предпринять соответствующие шаги, чтобы гарантировать, что были приняты необходимые меры безопасности, и репозиторий, подобный этому, должен объяснять некоторые из этих подходов и включать их в примеры. На мой взгляд, это приемлемая цена за гибкость междоменной аутентификации с ограничением по времени для некритичных сервисов.
При проектировании комплексного решения он, вероятно, будет включать файлы cookie сеанса в конце аутентификации и может быть расширен для включения разовых токенов и т. Д., Где это необходимо. Дело в том, что это возможно, и хотя есть места, где это может пойти не так и подвергнуть риску, во многих случаях он дает возможность создавать более богатые и компактные приложения, и по этой причине я не считаю, что это репо следует объединять, как предлагается регистратором проблем.
Мне кажется, что склонность пытаться получить лучшее из обоих миров, используя JWT в качестве строки сеанса, вызывает проблемы - наиболее поразительно, возможно, конфликтующие периоды тайм-аута / TTL. Он также применяет те же ограничения доступа к домену, которых мы, возможно, пытались избежать в первую очередь, поэтому включение этого в базовый пример вполне может заставить людей спросить, зачем вообще использовать JWT?

Использование JS в качестве зависимости довольно незначительно - в контексте гибридного мобильного SPA маловероятно, что вам понадобится разместить бесплатный клиент JS. Предположение, что это проблема, в то же время утверждение, что redis предоставляет эффективный вариант для хранения сеансов, кажется немного противоречивым.
Истечение срока в JWT не бесполезно, так как обеспечивает тайм-аут сеанса, который должен обрабатываться либо путем обновления (точно так же, как обновляются сеансы cookie), либо требовать повторной аутентификации. Наличие подписи JWT гарантирует, что он не был подделан, и, таким образом, устраняет абсолютное требование проверки на постоянное хранилище на стороне сервера, хотя это можно сделать, если желательно, и дает тот же результат, что и сеансы cookie, без такой самоуверенной реализации и с возможность использовать кросс-домен, если это возможно. В гибридном мобильном приложении хранение файлов cookie или JWT в локальном хранилище снова дает больший контроль. Возражения против использования локального хранилища по сравнению с безопасностью реализации браузера являются вопросом доверия к поставщику и согласия с их обработкой этих учетных данных.
Гибкость полезна для многих разработчиков мобильных гибридных SPA, но требует понимания ограничений.
JWT можно сделать недействительным, просто изменив ключ подписи, и снова это дает гибкость - вы можете использовать общий общий закрытый ключ подписи для разных служб или генерировать случайный сеанс для каждого пользователя и реализовать своего рода преимущества отказа от сеансовых файлов cookie.
Почти все современные JS-фреймворки поддерживают JWT, и было бы трудно найти основную платформу, которая не поддерживает - некоторые, однако, вероятно, не должны (плагин Wordpress JWT ... хм ... не смотрел, но заставляет меня нервничать).
Использование JWT должно включать предысторию OAUTH, а также компромиссы и преимущества использования сеансов cookie. Для меня есть реальные преимущества в работе для средних мобильных гибридных разработчиков, использующих несколько сервисов, но есть ловушки, в которые легко попасть. Для полной иллюстрации нам может потребоваться множество примеров.

Мои _оригинальные аргументы_ в пользу использования JWT в качестве токена для авторизации заключаются в том, что проверка JWT привязана к ЦП (мой «старый» ноутбук может проверять 180 тыс. JWT в секунду_), в отличие от того, если бы мы использовали простой токен и должны были найти его. в памяти (или в базе данных) операция будет связана с вводом-выводом (или хуже - с привязкой к сети), что будет значительно медленнее.
http://stackoverflow.com/questions/868568/what-do-the-terms-cpu-bound-and-io-bound-mean

Наша система управления сеансом _вначале_ проверяет, что JWT действителен, проверяя, что он _подписан_ с помощью нашего ключа - и отклоняет сообщение _вначале_, если это не так, и _ затем_ проверяет, не был ли сеанс еще не признан недействительным (например, из-за выхода пользователя из системы) .

Я знаю, что JWT, возможно, не были _разработаны_ для использования в качестве токенов в заголовках авторизации, но я не думаю, что я полностью понимаю_, почему это «плохая идея», учитывая, что это _ быстрее_, чем другие системы управления сеансами ...

Примечание. Я все еще согласен с тем, что использование «без файлов cookie» - неправильный способ начать этот файл readme / учебник. 👍