Спецификация JWT описывает только полезную нагрузку и то, как она отправляется, но оставляет протокол аутентификации открытым, что обеспечивает гибкость, но, к сожалению, гибкость может привести к антипаттернам и неправильному дизайну.
Я ищу хорошо продуманный и проверенный корпоративный шаблон для аутентификации JWT, который я мог бы использовать или адаптировать, но мне не удалось найти что-то полное.
То, о чем я думал, это:
- если заголовок авторизации не встречен, или токен JWT недействителен, или истек срок действия, отправьте HTTP 401
- для аутентификации используйте / входите в REST канал, отправьте имя пользователя и пароль как объект JSON
- чтобы поддерживать токен в рабочем состоянии, используйте / оставляйте канал REST / keepalive, вызывайте его каждые N (5) минут, получайте новый токен JWT и заменяйте существующий после каждого вызова (токен истекает через M (15) минут)
Однако меня беспокоит необходимость в этом / keepalive канале. С другой стороны, это вынуждает меня предотвращать истечение срока действия аутентификации, даже если пользователь отсутствует (решение, если мы хотим, чтобы keepalive еще не было выполнено), и, конечно, это дополнительные вызовы и дополнительное усложнение протокола. Что было бы интересно, так это то, что сервер автоматически продлевает токен. В среде, основанной на сеансах, это происходит путем сброса метки времени, однако здесь серверу придется отправлять новый токен, возможно, не каждый раз, а только после истечения срока действия токена через R (скажем, 10) минут. Но размещение его в теле ответа будет означать изменение протокола ответа JSON (следовательно, решение является инвазивным и непрозрачным), и добавление дополнительного заголовка HTTP, который может обработать клиент, не обязательно может быть хорошим шаблоном. Я'
Есть ли готовые шаблоны предприятия, которые отвечают моим открытым позициям? Является ли мой проект протокола надежной идеей? Я предпочел бы использовать что-то готовое, чем дизайн с нуля.
Ответы:
JWT ( введение в JSON Web Token ) - это просто формат токена, аутентификация - это нечто, выходящее за рамки данной спецификации. Он действительно широко используется в системах аутентификации, но вы также можете использовать его для совершенно разных сценариев, поэтому имеет смысл не включать специфические ограничения аутентификации в эту спецификацию.
Если вы ищете руководство по аутентификации, вам следует обратиться к семейству спецификаций OpenID Connect . Кроме того, если ваша система состоит из HTTP API и вы заинтересованы в предоставлении делегированного доступа к этим API для вашего собственного или стороннего клиентского приложения, вам следует обратиться к спецификации OAuth 2.0 .
Существуют дополнительные протоколы, связанные с аутентификацией, такие как SAML и WS-Federation, которые все еще широко используются в корпоративных сценариях, но их значительно сложнее реализовать.
О ваших конкретных открытых точках:
Хотя OAuth2 и OpenID Connect могут показаться более простыми в реализации, чем некоторые из его предшественников, они все еще достаточно сложны, чтобы гарантировать некоторую осторожность и реализовывать их самостоятельно, только если вы готовы потратить значительное количество времени и ресурсов. Как правило, лучше использовать сторонние библиотеки или службы, которые делают это за вас.
Наконец, эти протоколы охватывают множество сценариев, поэтому в некоторых ситуациях они могут быть излишними.
источник
Я не думаю, что вам нужен канал поддержки активности. Ваша полезная нагрузка может (и рекомендуется) содержать информацию об истечении срока действия, предоставляемую сервером (в
expключе, согласно стандарту ), когда токен генерируется при входе в систему. Если используется токен с истекшим сроком действия (который, очевидно, определяется сервером, который доверяет только тому, что находится в токене, если подпись проверяется), сервер просто отклоняет его с HTTP 401, побуждая клиента к повторной аутентификации.Клиенты, тем временем, могут быть активными. Раздел полезной нагрузки не зашифрован, и, поскольку клиент может прочитать его, клиент может определить, когда запрос будет отправлен с токеном с истекшим сроком действия, и, следовательно,
/loginповторно вызвать его, если токен истек.В качестве альтернативы, REST позволяет отправлять гипермедиа информацию как «движок состояния», и поэтому, если вы хотите, вы можете сделать свой JWT одноразовым, а также с истечением срока действия. Каждый запрос будет генерировать новый JWT, который возвращается в ответе клиенту, либо в содержимом, либо, что более вероятно, в заголовке ответа, как это делает hapi-auth-jwt2 .
источник