Jwt-auth: [вопрос] Вариант использования Headless API

Архитектура потока авторизации в этом плагине великолепна; Я понимаю опасения по поводу безопасности. Хотя это отключает, возможно, основной вариант использования такой функции: Wordpress в качестве безголовой CMS.

Отключает безголовую аутентификацию CMS

Безголовая CMS потребует от пользователей входа в систему через username и password . Когда у пользователя есть JWT, он может отправлять аутентифицированные запросы к защищенным ресурсам, в безголовой среде CMS было бы запретительно и нелогично просить пользователей генерировать токены API.

Безопасность должна быть реализована с помощью привилегий RBAC, ролей и обязанностей пользователей, определяющих, что именно защищено в API. Проблемы безопасности могут быть смягчены с помощью очень строгих значений по умолчанию для RBAC. В Wordpress уже есть отличная структура ролей и обязанностей.

Для решения реальных проблем безопасности:

• Долгоживущие токены? Сделайте их недолговечными токенами.
• Опасения, что долгоживущие токены могут быть украдены? Так же как и токены API, нулевой аргумент.
• Лучшие практики JWT диктуют краткосрочные tokens и долгоживущие refresh_tokens (токены обновления могут быть отозваны). Таким образом, это более безопасно, чем раздача токенов API с бесконечным сроком службы, которые могут быть потеряны.

Разве это не просто OAuth2?

Этот подход, по сути, представляет собой сценарий предоставления токена oAuth2 "personal access" . Таким образом, я бы поставил под сомнение преимущества такого подхода к серверу аутентификации пользовательского токена, как этот, по сравнению с надлежащей стандартной реализацией oAuth2? Если безопасность здесь является главной заботой, то этот подход действительно представляет риски для безопасности? например, проверенная в бою реализация oAuth2, такая как php-league-oatuh-2

Я вижу единственный жизнеспособный вариант использования текущего потока аутентификации application-to-application аутентификации? oAuth2 предлагает несколько методов потока аутентификации для предоставления токенов. Одним из них является то, что этот подход использует "personal access" , а другим является то, что я описываю токены "password access" . Полная реализация oAuth2 позволила бы реализовать оба этих сценария и многое другое...

Дальше

Мы считаем, что внедрение WP-API и, следовательно, модернизация экосистемы Wordpress в целом значительно ускорились бы, если бы такие вещи, как аутентификация API без сохранения состояния, были легко доступны для разработчиков.

Это всего лишь размышления, и я хотел бы обсудить и внести свой вклад!

Отличная работа!

wp-безголовая команда