Tokens web Json. Encabezado nombrar convenciones, formato y problemas de seguridad

Hay muchas incógnitas aquí, pero esta es mi oportunidad de responder según las mejores prácticas de seguridad en general.

  

1. ¿Debo firmar mi token de referencia con RSA antes de pasarlo a la   cliente?
  

Las firmas se pueden utilizar para la autenticidad, la integridad y el no repudio. En este caso, la integridad es la única que parece tener sentido. Si esto es requerido, definitivamente debes firmar el token. Es obligatorio, si el token es autodescriptivo, es decir, contiene datos que pueden ser manipulados por el cliente (como un JWT). Escribí publicación de blog sobre integridad. RSA no puede ser requerido. Un simple HMAC puede ser suficiente para usted. Su caso de uso realmente determina si necesita criptografía asimétrica aquí.

  

2. ¿Debo firmar mi token de actualización con RSA? Obviamente, como referencia.   token, no almacena ninguna información crítica y por lo tanto estoy   No estoy seguro de eso.
  

Consulte 1. Dado que no se lo pasa al cliente y parece ser un token opaco. Puedes salirte sin firmar esto.

  

3. ¿Debo firmar mi token de acceso con RSA, si nunca se pasa al cliente y solo se usa en el lado del servidor? Supongo que debería, solo   como en el caso de contraseñas con hash almacenadas en la base de datos.
  

Ver 1. Si no se lo pasa al cliente, es imposible que el cliente lo modifique. Puede que aún sea necesaria la integridad, depende de su caso de uso.

  

4. ¿Cuáles son las convenciones de nomenclatura para el encabezado HTTP en las que paso mi token de referencia del servidor al cliente? ¿Está bien usar sólo algunos   encabezado arbitrario como X-Reference-Token?
  

Sí, está bien. Dado que el esquema es personalizado, no creo que sea perjudicial usar un encabezado personalizado para un token personalizado.

  

5. ¿En qué encabezado debo pasar el token de referencia del cliente al servidor? ¿Debo usar la Autorización: Portador ... (parece un   convención estándar) o está bien usar la misma   X-Reference-Token: ...
  

Autorización: el portador es probablemente mejor aquí. Sin embargo, parece que en 6. está utilizando cookies para el token de referencia, en cuyo caso no es necesario un encabezado adicional para enviarlo.

  

6. ¿Es seguro (supongo que no) pasar el token de actualización al cliente? Y   Si no, ¿cómo lo almacenan? El token de referencia se almacena en el lado del cliente   cookies y pasadas con cada solicitud del cliente al servidor, acceso   El token nunca se pasa al cliente y se almacena en el caché del lado del servidor   y ¿dónde debo guardar mi token de actualización?
  

Su esquema es una caja negra para mí, pero parece que el token de acceso nunca llega al cliente, por lo que el token de actualización tampoco debería. En un mecanismo de autenticación regular como OAuth, estos dos tokens requieren la misma cantidad de seguridad. Sin contar el hecho de que los tokens de actualización viven más tiempo.

  

7. ¿Es seguro usar el valor de token de referencia sin procesar como clave, por lo que obtengo   ¿token de acceso desde la caché del lado del servidor? Digamos, mi token de referencia es   solo un GUID, ¿es lo suficientemente seguro para usar este GUID como una clave por   ¿Cuál es mi token de acceso almacenado? ¿O es más seguro obtener esta clave?   ¿De GUID por algunas transformaciones?
  

De nuevo, tu esquema es una caja negra. Me parece que su token de referencia es en realidad un ID de sesión. En este caso, no debe ser un GUID, sino un token opaco aleatorio, como se describe aquí . Está bien almacenar el ID de sesión como la clave para obtener el token de acceso de su caché.

Todo lo que describí anteriormente se basa en mi comprensión muy limitada de su esquema. En general, no debe ejecutar su propio esquema de autenticación / autorización. Me parece que tiene una aplicación web con administración de sesión que utiliza cookies y un OAuth para acceder a algunos recursos en el servidor.

Echa un vistazo a OAuth, puede simplificar bastante tu vida.