Una alternativa simple y sin estado a la autenticación básica HTTP para API's

Navega tus respuestas
2

Muchas API (servicios) de hoy usan OAuth, autenticación básica HTTP o claves API para autenticar a sus usuarios.

Mi objetivo es encontrar una forma simplista y segura para autenticar a los usuarios en una aplicación web del lado del cliente en una stateless para un servicio .

Métodos de autenticación

Esta es mi opinión sobre algunos de los métodos de autenticación:

  1. OAuth parece una gran solución, pero parece muy complicada para la configuración y parece excesivo para un solo servicio.

  2. Según OWASP " la autenticación HTTP básica no es segura y no debe utilizarse en aplicaciones ".

  3. El uso de las claves de API sencillas en una aplicación web del lado del cliente no lo hace Parece una mejora en comparación con la autenticación HTTP básica.

Usando tokens encriptados

Mi idea alternativa es usar tokens encriptados que puedan ser verificados por el servicio.

  1. El texto simple del token contendrá el nombre de usuario , contraseña & la fecha de caducidad del token.

  2. El texto sin formato se cifrará usando una clave secreta que solo es conocida por el servidor.

  3. El texto sin formato se cifrará en el servidor utilizando AES en Modo GCM , para que la integridad no pueda ser manipulada.

El usuario debe iniciar sesión con su nombre de usuario y contraseña para recibir un token . Este token se envía con cada solicitud y se puede verificar en el servidor.

Para ilustrar: 

+----------+                                          +-----------+
|          +------      Login with user:pass     ---->+           |
|  Client  |                                          |    API    |
|          +<----       Send encrypted token      ----|           |
|          |                                          |           |
|          +------    Use token to authenticate  ---->+           |
+----------+                                          +-----------+

Verificación

La verificación se puede realizar mediante:

  1. Descifre el token utilizando la clave secreta .
  2. Verifique nombre de usuario y contraseña .
  3. Comprueba si el token ha caducado .

Pro's

Posibles ventajas de este enfoque:

  1. Los tokens se pueden almacenar en localStorage para mitigar los ataques CSRF y los usuarios pueden cerrar la sesión borrando el almacenamiento local.
  2. La información de inicio de sesión de texto simple no se envía en todas las solicitudes.
  3. Los tokens pueden caducar.

Contras

Posibles contras de este enfoque:

  1. Más carga en el servidor al descifrar cada solicitud.
  2. Un token está enlazado a un servidor específico.

¿Qué crees que es una buena solución? ¿Conoces otras buenas alternativas?

    
pregunta swordsecurity 20.06.2018 - 14:17
fuente

1 respuesta

4

Su solución propuesta es casi idéntica a los JSON Web Tokens (JWT), que son precisamente eso:

  • Un token sin estado que contiene información sobre el usuario
  • Firmado y / o encriptado usando clave secreta o asimétrica compartida
  • Marcado con una marca de tiempo de caducidad

Consulte enlace para obtener más información. Le servirían muy bien utilizando este estándar en lugar de rodar el suyo, ya que ya existen muchas bibliotecas bien probadas para el manejo de estos tokens.

Tenga en cuenta que generalmente no es necesario almacenar la contraseña en el token, ya que el hecho de que se haya cifrado o firmado con su clave privada demuestra que fue creado por su rutina de autenticación. Esto brinda la importante ventaja de que puede tener un servicio de autenticación completamente independiente, que verifica las contraseñas y genera tokens, mientras que su aplicación principal solo sabe cómo leer los tokens.

En lo que respecta a vincular cosas a un servidor en particular, puede manejar múltiples servidores de una de estas dos formas:

  • Use el cifrado simétrico, con el mismo secreto compartido instalado en todos sus servidores, pero aún así es imposible que otra persona lo descubra.
  • Utilice el cifrado asimétrico y genere una clave privada diferente en cada servidor que necesite crear tokens, e implemente las claves públicas correspondientes en cada servidor que necesite leer tokens .
respondido por el IMSoP 20.06.2018 - 14:30
fuente

Lea otras preguntas en las etiquetas

Por qué la verificación previa de CORS no está disponible para solicitudes POST cuando Content-Type es application / x-www-form-urlencoded ¿Cómo se aplicará la transparencia del certificado?