Traducción de token OAuth (opaco a JWT)

2

He visto un par de charlas que sugirieron el uso de la traducción del token de OAuth en la puerta de enlace de la API del token opaco al token de JWT. ¿Cuáles son las ventajas y desventajas de este enfoque, quién debería usarlo?

Si estamos usando HTTPS, no creo que esto haga ninguna diferencia en términos de fugas de token. Dos desventajas serían ahora que los clientes no pueden deducir lo que pueden hacer o si su token sigue activo, y debemos poner toda nuestra API detrás de una puerta de enlace *.

*: Quiero decir que también podríamos ponerlos detrás de n gateways siempre que hablen con un único Servidor de Autorización, pero esto supone n veces la carga para el AS.

Aquí hay un ejemplo de conversación enlace

    
pregunta EralpB 25.04.2017 - 10:02
fuente

1 respuesta

2

Un comentario sobre eso:

  

ahora los clientes no pueden deducir lo que pueden hacer o si su token sigue activo

La forma más segura de almacenar el JWT es probablemente en un enlace (para evitar XSS) una cookie segura (+ tomar medidas contra XSRF). Si lo hace, el código del lado del cliente no puede verificar directamente el JWT de todos modos.

En cuanto a su pregunta inicial, creo que puede ayudar a dar más control sobre la revocación / caducidad de la sesión. Si entrega el JWT al usuario final, no podrá hacer nada hasta que se alcance "exp" (y el emisor haya decidido este parámetro, que podría no coincidir con sus propias políticas). Con el identificador opaco, usted mantiene el control y puede revocar el acceso en cualquier momento. De alguna manera, mantienes la administración de sesiones a la antigua usanza mientras aún aprovechas JWT para la autenticación delegada.

enlace

  

A diferencia de las sesiones, que pueden ser invalidadas por el servidor siempre que lo desee, individual   Los tokens JWT sin estado no pueden ser invalidados. Por diseño, serán   válido hasta que caduquen, sin importar lo que pase.

enlace

  

Para un servicio con estado, usted entrega un nuevo producto de uso único y de corta duración.   token para cada servicio, que luego se intercambia en el servicio   En sí, para una sesión en ese servicio específico. Nunca usas el   token en sí como la sesión.

    
respondido por el Mathieu Rey 29.07.2017 - 07:22
fuente

Lea otras preguntas en las etiquetas