jhipster 2: В чем разница между вариантами аутентификации?

Я обновил генератор jhipster с версии 1 до версии 2. В предыдущей версии нам приходилось выбирать аутентификацию при создании нового проекта. У нас был выбор между аутентификацией Cookie и аутентификацией Token (с OAuth). Это было очень ясно для меня. Но в версии 2.1.1 у нас теперь есть три варианта:

1 > HTTP Session Authentication (stateful, default Spring Security mechanism)
2 > OAuth2 Authentication (stateless, with an OAuth2 server implementation)
3 > Token-based authentication (stateless, with a token)

Я хочу использовать аутентификацию как для веб-приложений, так и для мобильных приложений (ionic-framework), какая из них между 2 и 3? Делает ли этот выбор масштабируемым мое приложение с помощью кластеров? Спасибо


person Pracede    schedule 09.02.2015    source источник
comment
Официальная документация довольно четко объясняет разницу между различными типами аутентификации jhipster.github.io/security.html   -  person Greg    schedule 13.02.2015


Ответы (1)


вы получите основную информацию о типе аутентификации jhipster здесь

http://jhipster.github.io/security/

исходя из моего личного опыта работы с ionic-framework с REST API jhipster, я могу сказать, что не используйте HTTP Session Authentication для мобильного приложения (ionic-framework), потому что мобильные приложения не используют файлы cookie в целом, от чего зависит аутентификация сеанса HTTP.

И Oauth2, и JWT отлично работают с ионным гибридным приложением

Аутентификация сеанса HTTP

Это «классический» механизм аутентификации Spring Security, но мы значительно улучшили его. Он использует сеанс HTTP, поэтому это механизм с отслеживанием состояния: если вы планируете масштабировать свое приложение на нескольких серверах, вам необходимо иметь балансировщик нагрузки с фиксированными сеансами, чтобы каждый пользователь оставался на одном сервере.

Аутентификация OAuth2

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

Самая большая проблема с OAuth2 заключается в том, что для хранения токенов безопасности требуется несколько таблиц базы данных. Если вы используете базу данных SQL, мы предоставляем необходимый журнал изменений Liquibase, чтобы эти таблицы создавались автоматически.

Поскольку Spring Security поддерживает только OAuth2 с базами данных SQL, мы также внедрили собственную версию MongoDB. Мы генерируем для вас всю реализацию OAuth2 для MongoDB, а также необходимую конфигурацию MongoDB.

В этом решении используется секретный ключ, который должен быть настроен в вашем файле application.yml как свойство «authentication.oauth.secret».

Аутентификация JWT

Аутентификация JSON Web Token (JWT), как и OAuth2, представляет собой механизм безопасности без сохранения состояния, поэтому это еще один хороший вариант, если вы хотите масштабироваться на нескольких разных серверах.

Этот механизм аутентификации не существует по умолчанию в Spring Security, это специфичная для JHipster интеграция проекта Java JWT. Его проще использовать и реализовать, чем OAuth2, так как он не требует механизма сохранения, поэтому он работает со всеми параметрами SQL и NoSQL.

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

Секретный ключ должен быть настроен в файле application.yml как свойство jhipster.security.authentication.jwt.secret.

person Abhishek Patil    schedule 14.05.2016
comment
Можете ли вы или кто-нибудь объяснить это в фактической архитектуре JHipster? Я имею в виду, я видел, что генератор создает один и тот же код для шлюза, JHipsterRegistry и микросервисов для аутентификации (например, TokenProvider), поэтому это не очень просто, ведь конечные точки должны иметь механизм аутентификации и то, как они будут обмениваться информацией об аутентификации. - person carpinchosaurio; 13.07.2016
comment
что касается аутентификации oauth2, протокол действительно не имеет состояния, но, как я вижу, Jhipster реализовал его с сохранением состояния между клиентом и сервером (см. в документации, а также метод UserService::clearUserCaches) - person orirab; 13.01.2019