Java Spring JWT с вопросами обновления рабочего токена

Question

У меня есть несколько вопросов относительно рабочего процесса обновления токена API JWT с использованием Java Spring.

У меня пока что есть:

1. Пользователь входит в / users / login - в случае успеха возвращается ответ с 2 заголовками Авторизация и Обновление. Которые содержат 2 токена - один с коротким сроком действия 30 минут и один с более длинным сроком действия 4 часа.
2. Затем он может получить доступ ко всем остальным конечным точкам, используя заголовок авторизации.
3. Если в какой-то момент, получая доступ к конечной точке, срок действия его токена истек, он получает ошибку (НЕ РАЗРЕШЕНО).
4. И должен сделать запрос к / token / refresh с токеном обновления, который ему дали.

Вопросы:

• Я настроил так, чтобы токен авторизации имел утверждение: type = auth и токен обновления имеет утверждение: type = refresh. Какой самый лучший способ различать два жетона.
• Какой должна быть ошибка на шаге 3 (вместо несанкционированного), чтобы отличить ее от запроса без действительного токена
• / token / refresh в настоящее время не запрашивает аутентификацию. Должно ли это?
• Если конечной точкой / token / refresh является POST с заголовком, POST с параметрами или GET с заголовком.

Answer 1

Как лучше всего различать два жетона?

Жетон обновления вообще не должен быть JWT. Я предпочитаю просто генерировать случайную буквенно-цифровую строку. Обновить токен не несет никакой дополнительной информации. Требуется поиск в базе данных, чтобы подтвердить правильность токена обновления. Вы отличаете их по тому, где они появляются в вашем запросе. Токен авторизации (токен доступа) должен появиться в заголовке по вашему выбору.

Какой должна быть ошибка на шаге 3 (вместо несанкционированного), чтобы отличить ее от запроса без действительного токена

Отправка 401 Несанкционированным - именно такой способ. 401 сообщает клиенту, что он не может получить доступ к ресурсу сейчас, но он может предпринять действия, чтобы он мог снова получить доступ к ресурсу (маркер входа / обновления). 403 с другой стороны сообщит клиенту, что ресурс ему не принадлежит, и ему придется запросить разрешения, например, связавшись с администратором

/ token / refresh в настоящее время не запрашивает аутентификацию. Должно ли это?

Нет, аутентификация не требуется.

Если конечной точкой / token / refresh является POST с заголовком, POST с параметрами или GET с заголовком.

Как правило, конечная точка GET должна быть доступна только для чтения и не изменять какие-либо ресурсы. Конечные точки POST и PUT предназначены для мутаций. В этом я бы использовал POST с параметрами и выделенным URL, например, / Маркер / обновление