La especificación JWT describe solo la carga útil y cómo se envía, pero deja abierto el protocolo de autenticación, lo que permite la flexibilidad, pero desafortunadamente, la flexibilidad puede conducir a antipatterns y mal diseño.
Estoy buscando un patrón empresarial bien pensado y probado para la autenticación JWT, que podría usar o adaptar, pero no pude encontrar algo completo.
Lo que estaba pensando es:
- cuando no se cumple con el encabezado de autorización, o el token JWT no es válido o ha caducado, envíe HTTP 401
- Para autenticar, use / inicie sesión en el canal REST, envíe el nombre de usuario y la contraseña como objeto JSON
- Para mantener vivo el token, use el canal REST / keepalive, llámelo cada N (5) minutos, reciba un nuevo token JWT y reemplace el existente después de cada llamada (el token expira después de M (15) minutos)
Sin embargo, lo que me perturba es la necesidad de ese canal / keepalive. Por otro lado, me obliga a evitar que caduque la autenticación, incluso si el usuario está ausente (la decisión, si queremos que Keepalive aún no se cumpla) y, por supuesto, esas son llamadas adicionales y complicaciones adicionales al protocolo. Lo que sería interesante es que ese servidor prolonga automáticamente el token. En el entorno basado en la sesión, esto ocurre al restablecer la marca de tiempo, aquí, sin embargo, el servidor tendría que enviar un token nuevo, tal vez no cada vez, pero una vez que el token expire en R (digamos, 10) minutos. Pero colocarlo en el cuerpo de respuesta significaría modificar el protocolo de respuesta JSON (por lo tanto, la solución es invasiva y no transparente), y colocar un encabezado HTTP adicional que el cliente pueda procesar no necesariamente puede ser un buen patrón. YO'
¿Hay algún patrón empresarial listo que responda a mis puntos abiertos? ¿Es mi borrador de protocolo una idea confiable? Prefiero usar algo listo que diseñar desde cero.