Java Spring JWT с вопросами о рабочем процессе обновления токена
У меня есть несколько вопросов относительно рабочего процесса обновления токенов API JWT с использованием Java Spring.
У меня пока есть это:
- Пользователь входит в / users / login - в случае успеха возвращается ответ с 2 заголовками Authorization и Refresh. Которые содержат 2 токена - один с коротким истечением 30 минут и один с более длительным сроком действия 4 часа.
- Затем он может получить доступ ко всем остальным конечным точкам с помощью заголовка авторизации.
- Если в какой-то момент доступа к конечной точке его токен истек, он получает сообщение об ошибке (НЕСАНКЦИОНИРОВАНО).
- И должен сделать запрос к / token / refresh с токеном обновления, который ему был дан.
Вопросов:
- Я настроил его так, чтобы токен авторизации имел требование: type = auth и токен обновления имеет требование: type = refresh. Как лучше всего различить два жетона.
- Какой должна быть ошибка на шаге 3 (вместо несанкционированной), чтобы отличить ее от запроса без действующего токена
- / token / refresh в настоящее время не запрашивает аутентификацию. Должен ли он?
- Должна ли конечная точка / token / refresh быть POST с заголовком, POST с параметрами или GET с заголовком.
Ответы 1
What is the best way to distinguish the two tokens.
Токен обновления совсем не обязательно должен быть JWT. Я предпочитаю просто генерировать случайную буквенно-цифровую строку. Токен обновления не несет никакой дополнительной информации. Для подтверждения действительности токена обновления требуется поиск в базе данных. Вы различаете их по тому, где они указаны в вашем запросе. Токен авторизации (токен доступа) должен появиться в выбранном вами заголовке.
What should be the error in step 3 (instead of unauthorized) to distinguish it from a request without a valid token
Отправка 401 Unauthorized - это как раз то, что нужно сделать. 401 сообщает клиенту, что он не может получить доступ к ресурсу сейчас, но он может предпринять действия, чтобы снова получить доступ к ресурсу (токен входа / обновления). 403 с другой стороны сообщит клиенту, что ресурс ему не принадлежит, и ему придется запрашивать разрешения, например связавшись с администратором
/token/refresh doesn't ask for authentication currently. Should it?
Нет, аутентификация не требуется.
Should the /token/refresh endpoint be a POST with header, POST with parameters or a GET with header.
Как правило, конечная точка GET должна быть доступна только для чтения и не изменять какие-либо ресурсы. Конечные точки POST и PUT предназначены для мутаций. В этом случае я бы использовал POST с параметрами и выделенным URL-адресом, например. / токен / обновление
Да, конечно, вы можете представить токены обновления как JWT. Но в этом есть одна загвоздка. Срок годности JWT «высечен на камне». Он будет аннулирован через 4 часа, точка. Однако существует множество сценариев, когда вы хотите, чтобы токен обновления скоро истек. Пример 1: Явный выход из системы -> пользователь нажимает кнопку выхода из системы. Пример 2: вы хотите немедленно заблокировать учетную запись и не позволять пользователю больше использовать токен обновления. Пример третий: запрос на обновление выглядит подозрительно -> он исходит от другого пользовательского агента, из другой страны ...
Вы можете проверить полный пример на github.com/ygor-sk/stackoverflow/tree/master/…
Большое тебе спасибо
@ygor отличный ответ, спасибо за пример, однако в этом примере передача токена jwt на любую конечную точку, для которой требуется токен, возвращает 401, что может быть причиной.
Большое тебе спасибо. Если я не хочу хранить токены обновления в базе данных, есть ли способ это сделать?