Спецификация JWT описывает только полезную нагрузку и то, как она отправляется, но оставляет протокол аутентификации открытым, что обеспечивает гибкость, но, к сожалению, гибкость может привести к антипаттернам и неправильному дизайну.
Я ищу хорошо продуманный и проверенный корпоративный шаблон для аутентификации JWT, который я мог бы использовать или адаптировать, но мне не удалось найти что-то полное.
То, о чем я думал, это:
- если заголовок авторизации не встречен, или токен JWT недействителен, или истек срок действия, отправьте HTTP 401
- для аутентификации используйте / входите в REST канал, отправьте имя пользователя и пароль как объект JSON
- чтобы поддерживать токен в рабочем состоянии, используйте / оставляйте канал REST / keepalive, вызывайте его каждые N (5) минут, получайте новый токен JWT и заменяйте существующий после каждого вызова (токен истекает через M (15) минут)
Однако меня беспокоит необходимость в этом / keepalive канале. С другой стороны, это вынуждает меня предотвращать истечение срока действия аутентификации, даже если пользователь отсутствует (решение, если мы хотим, чтобы keepalive еще не было выполнено), и, конечно, это дополнительные вызовы и дополнительное усложнение протокола. Что было бы интересно, так это то, что сервер автоматически продлевает токен. В среде, основанной на сеансах, это происходит путем сброса метки времени, однако здесь серверу придется отправлять новый токен, возможно, не каждый раз, а только после истечения срока действия токена через R (скажем, 10) минут. Но размещение его в теле ответа будет означать изменение протокола ответа JSON (следовательно, решение является инвазивным и непрозрачным), и добавление дополнительного заголовка HTTP, который может обработать клиент, не обязательно может быть хорошим шаблоном. Я'
Есть ли готовые шаблоны предприятия, которые отвечают моим открытым позициям? Является ли мой проект протокола надежной идеей? Я предпочел бы использовать что-то готовое, чем дизайн с нуля.