Jwt-auth: Обновленный пользовательский интерфейс Token Flow

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

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

Я понимаю, что вы пытаетесь сказать здесь, но в то же время вы предлагаете то, что требовать от пользователя входа в WordPress и создания пары ключей как-то сложно для нетехнических пользователей, которые хотят сгенерировать токен. через REST API программно. Я бы сказал, что это совсем не _ нетехнические_ пользователи.

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

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

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

Сказать пользователю войти в WordPress и перейти в свой профиль для создания пары ключей - небольшая плата за безопасность. Кроме того, направления очень простые.

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

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

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

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

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

Вдобавок - меня беспокоит добавление дополнительного метода для отмены сеансов - WordPress уже имеет кнопку «Выход из системы везде, где еще» на странице профиля - как пользователь, я ожидал бы, что это также приведет к выходу меня из любых приложений ( или хотя бы подскажите, хочу ли я это сделать?)

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

Не обеспечивает дополнительной безопасности
Если у меня, как у злоумышленника, уже есть ваше имя пользователя и пароль, я ничего не могу сделать, как вы (при условии, что нет 2FA).

Категорически не согласен. Этот подход обеспечивает дополнительную безопасность для доступа к вашим ресурсам REST, и если это не очевидно, нам нужна дополнительная документация, чтобы сделать это очевидным. Вы утверждаете, что если у кого-то уже есть ваши учетные данные, вы облажались, но вы также предлагаете использовать их для предоставления доступа к REST API. Если вы хотите получить доступ к REST именно так, используйте Basic Auth. Потому что это именно то, что мы реализовали бы, если бы использовали user:pass для создания токенов.

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

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

Я на 100% открыт для создания потока аутентификации для приложений, когда вы переходите к нему, вас просят войти в WordPress с любыми дополнительными функциями, такими как добавление 2factor, которые сгенерируют для вас пару ключей, а затем используют какой-то обратный вызов дайте приложению пару ключей. Тогда разработчикам приложений не нужно создавать массу плохих решений, и приложение не хранит свои user:pass .

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

Правильно, вы можете использовать много разных подходов.

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

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

А как насчет 2FA?
Мне интересно, можно ли разрешить ловушку, которую плагины 2FA могли бы использовать, чтобы сообщить клиенту «пожалуйста, попробуйте еще раз, предоставив токен 2FA», если он был необходим, но не предоставлен. Кроме того, можно использовать другой хук (или, возможно, тот же?), Чтобы позволить плагину 2FA проверить правильность предоставленного кода? Система JWT не будет делать никаких предположений о том, как реализована 2FA - это будет оставлено на усмотрение другого плагина - мы просто предоставим крючки, чтобы это стало возможным.

Это добавит IMO ненужный уровень сложности, который может создать множество запросов на поддержку.

Спасибо, что дочитали до этого места - все вышеперечисленное - ИМХО, но я надеюсь, что мы сможем немного упростить этот процесс для пользователей, чтобы он работал действительно хорошо для всех.

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

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

Разделение доступа и аутентификации является целенаправленным, и к нему нельзя относиться легкомысленно. Мы создаем потенциальную аутентификацию REST для 1/3 Интернета. Итак, пока у нас нет пути вперед, я убрал возможность создавать токены с учетными данными пользователя. Это не значит, что мы не можем добавить его обратно, просто нужно много обсудить, прежде чем мы это сделаем.

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

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

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

Кажется, то, что вы сказали здесь @valendesigns, могло бы быть возможным решением:

Я на 100% открыт для создания потока аутентификации для приложений, когда вы переходите к нему, вас просят войти в WordPress с любыми дополнительными функциями, такими как добавление 2factor, которые сгенерируют для вас пару ключей, а затем используют какой-то обратный вызов дайте приложению пару ключей. Тогда разработчикам приложений не нужно создавать массу плохих решений, и приложение не хранит их user: pass.

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

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

Я хотел бы получить больше информации об этой части:

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

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

То же самое должно произойти при удалении учетной записи.

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

Из-за этого очень сложно создать собственное мобильное приложение, которое может использовать этот метод Auth.

• Некоторое время назад я создал специальный плагин для (старого) плагина OAuth1a, который отображал зашифрованный (с коротким, устанавливаемым паролем) QR-код на странице администрирования приложений (когда имя приложения и URL-адрес обратного вызова совпадали с моим приложением), который затем передал информацию о клиентском приложении в мобильное приложение, чтобы затем позволить пользователю пройти аутентификацию.

Конечно (каламбур), JWT намного проще, чем OAuth1a;)

Поскольку пользователь должен сначала войти в Wordpress (надеюсь, через https), используя имя пользователя и пароль, я действительно не понимаю, в чем проблема безопасности, когда пара имени пользователя и пароля может получить токен доступа. ? Все это отправляется по одному и тому же «проводу» в конце дня? Конечно?

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

Просто нет разумного способа заставить мобильное приложение их вводить.

Я пробовал OAuth1a, OAuth2, а теперь и два JWT-плагина для реализации моих собственных приложений с доступом, и все они терпят неудачу «из коробки», без каких-либо взломов, чтобы попытаться заставить что-то работать для пользователя. Предполагается, что этот материал станет проще, не так ли?

Сторонний плагин JWT (с более чем 10000 установками) поддерживает пользовательский / пароль и хорошо работает для собственного мобильного приложения, которое я создавал. Но это не удается из-за отсутствия токенов обновления через плагин, вынуждая пользователя снова «войти в систему». (также требуется ручное редактирование wp-config)

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

Есть причина, по которой нет собственных мобильных приложений для публикации на сайтах wp.org. И это так.

Пожалуйста, пожалуйста, можно нам что-нибудь продвинуть? (Я уже много лет работаю над собственным приложением, ожидая «правильного» способа аутентификации пользователей с момента появления REST API)

:)

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

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

Проходят месяцы и месяцы, а это просто не решается.

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

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

Если вы хотите поучаствовать в этом, не стесняйтесь перейти к # core-restapi в Slack .