Каким образом сделать повторную аутентификацию с JWT?
У меня есть REST API приложение, аутентификация в которой реализована с помощью JSON Web Token (POST: "/api/auth/login"). При аутентификации пользователя в приложении, происходит генерация токена, в который зашифровывается логин зашедшего пользователя.
Приложение имеет эндпоинт (PATCH: "/api/user/{userId}/login") для обновления логина пользователя (статус ответа - 204 "No content"). Соответственно, когда происходит обновление логина в базе данных, то токен, который принадлежит данному пользователю, устаревает и перестаёт быть действительным, поскольку содержит устаревший логин. А для того, чтобы пользователь смог продолжить делать запросы приложению, ему нужно выдать новый токен, в котором будет зашифрован обновлённый логин. Т. е. по сути совершить повторную аутентификацию.
И тут у меня начинается, что называется "раздвоение личности": должен ли я, после того, как обновляю логин в БД, делать перенаправление на "/api/auth/login", типа: response.sendRedirect("/api/auth/login");
, а затем сразу отсылать новый токен в теле ответа.
Либо-же мне нужно просто отослать какой нибудь status code с заголовком или response body, что намекало бы клиентскому приложению, что для того, чтобы обновить токен и продолжить работать с API приложением, необходимо сделать POST запрос на "/api/auth/login". И если второй вариант, то какой status code отсылать: 100 "Continue", 102 "Processing", 103 "Early Hints", 202 "Accepted" или один из 3xx ?
Знаю, вопрос отностися к категории "основано на мнении", но всё-же хочется узнать плавила хорошего тона для данного случая.
Вам следует использовать http 401, приложение должно само знать куда ходить за токенами. Поместив эти информацию в веб сервис, вы создаёте лишнюю зависимость фактически отказываясь от плюсов jwt.
ID пользователя это нормализация данных.
Login пользователя, если id и login это не одно и то же, это денормализация данных.
Денормализация данных всегда должна иметь веские причины, если их нет данные должны быть нормализованы.
Вы данные денормализовали, но дальше прикладываете усилия для сохранения их согласованности с нормализованным данными, зачем?
Добрый день.
На мой взгляд должно быть 2 токена: refresh token и access token.
Первый токен используется для обновления второго токена и отсылается в запросе.
Второй токен используется для авторизации.
Соответственно, при обновлении логина перекинуть его на страницу входа. И после ввода логина и пароля вернуть на клиент 2 токена и сохранить в localStorage
На мой взгляд должно быть 2 токена: refresh token и access token.
Да, так у меня и есть, имеется два токена, как вы и сказали.
Соответственно, при обновлении логина перекинуть его на страницу входа. И после ввода логина и пароля вернуть на клиент 2 токена и сохранить в localStorage
А, ну да, точняк, можно и так сделать. Но ведь для пользователя будет быстрее, проще и удобнее, если это делать без его обязательства снова вводить логин и пароль. Как вы думаете?
А, ну да, точняк, можно и так сделать. Но ведь для пользователя будет быстрее, проще и удобнее, если это делать без его обязательства снова вводить логин и пароль. Как вы думаете?
Тут уже как вы решите. Я бы все-таки при смене логина и пароля просил бы авторизоваться заново.
Простой
Простой
