Проверка подлинности на основе токенов с помощью Spring и JWT

Question

Я использую Spring Security и JWT для реализации системы аутентификации / авторизации для моего мобильного приложения, и у меня есть пара сомнений относительно фактического дизайна системы. Это поток аутентификации / авторизации, позволяющий пользователям получать доступ к защищенным API REST:

1. Мобильное приложение отправляет запрос конечной точке / auth / token вместе с именем пользователя и паролем пользователя. пользователь использует базовую схему аутентификации. Сервер аутентифицирует пользователя, возвращающего токен доступа и обновления JWT.

2. Все последующие запросы к защищенным ресурсам, представленным конечными точками / api / **, выполняются, передавая токен доступа, которыйпроверено и доверено сервером. Логика проверки и доверения токена выполняется фильтром токенов, выполняемым перед BasicAuthenticationFilter пружины.

3. Если токен больше не действителен, клиент отправляет токен обновления (JWT)/ auth / refresh endpoint, которая проверяет этот токен и, если он является доверенным, возвращает новый токен доступа. Конечная точка / auth / refresh является публичной, но она опирается на тот факт, что подпись JWT должна быть действительной и надежной.

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

Answer 1

То, что вы описываете, в основном совпадает с потоком паролей oauth, за исключением отсутствующей клиентуры и секрета. Токен доступа и особенно токен обновления НИКОГДА не следует пересылать фактическому приложению, будь то приложение или веб-приложение.

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

Эти среды могут быть скомпрометированы.
Поэтому ваш токен доступа всегда должен быть сохранен на стороне сервера.

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

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

Например:

1. , еслипользователь входит, он получает взамен сессионный cookie.
   
2. После этого он мог также получить такой так называемый authCode для специального клиента (в данном случае, для ваших ресурсных серверов или прокси-сервера zuul) и областей видимости, таких как «read_profile, make_payments».
3. этот код authCode теперь отправляется на ваш сервер ресурсов или (прокси-сервер zuul сидит перед вашими конечными точками)
4. сам сервер ресурсов имеет свои собственные учетные данные клиента и теперь аутентифицируется на сервере аутентификации и получаетaccesstoken в обмен на код авторизации.

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