Usando OAuth 2.0 sin almacenamiento de token

Question

Usando OAuth 2.0 sin almacenamiento de token

#1 de rook (1 votos)
#2 de Julian Knight (0 votos)

7

Estoy creando un sistema para un producto que requiere autenticación y autorización. Naturalmente, he elegido utilizar OAuth 2.0, ya que es un protocolo de uso común y ha demostrado ser útil.

Estoy considerando implementar tokens sin almacenamiento, como se describe aquí: enlace

Esto me ahorraría muchos problemas con el almacenamiento de token y, por supuesto, significa que tengo que ir a la base de datos solo para el inicio de sesión inicial (cuando emito el token).

Ya que no estoy viendo esto en uso común, ¿hay algún inconveniente sustancial en este enfoque? ¿Es este un gran compromiso de seguridad?

Comprendo que no tendré alguna funcionalidad (como cerrar la sesión eliminando el token), pero creo que esto tendrá grandes beneficios cuando se trata de escalar la aplicación.

authentication oauth cryptography

pregunta AvnerSo 20.10.2014 - 17:41

fuente

2 respuestas

Lea otras preguntas en las etiquetas authentication oauth cryptography

Cuando TrueCrypt solicita volver a habilitar el montaje automático, ¿debería preocuparme? Password Vault - Enterprise

score 1 · Answer 1

El uso de tokens OAuth encriptados es un buen enfoque para satisfacer los requisitos de seguridad en RFC-6749 sección 10 . Los tokens OAuth cifrados son de uso común, Facebook es un buen ejemplo .

Los tokens de OAuth caducan según el parámetro expires_in . Lo que significa que un token dado sería válido por un corto tiempo después de que el usuario cierre la sesión, lo cual es un problema de muy bajo riesgo que la mayoría de las aplicaciones ignoran. Una vez que el usuario cierra la sesión, los ataques de sesión como XSS y CSRF no deberían ser posibles, incluso si el token OAuth sigue siendo válido.

score 0 · Answer 2

Los tokens de autenticación realmente solo parecen tener sentido para mí cuando su vida útil es corta. Por lo que puedo decir, este esquema no altera el hecho de que un token interceptado puede reproducirse, lo que parece ser el problema con todos los enfoques simples basados en token. (o quizás es solo tarde y no lo he leído correctamente :)

Ciertamente, me gustaría asegurarme de que cada cliente tenga un token independiente para que los riesgos se limiten a los clientes individuales.

Para ayudar a reducir la exposición de los tokens, haría que la aplicación del cliente elimine el token al vencimiento, si es posible & mantener la vida útil corta.

Mis propios experimentos con autenticación basada en token me han llevado a darme cuenta de que los tokens deben validarse con el origen del cliente (por ejemplo, al menos la dirección IP) periódicamente para intentar evitar la interceptación & repetición. Puede mantener esa información en el token (ya que está cifrada, obviamente no intente hacerlo con tokens no cifrados), pero el problema puede ser que los tokens se vuelvan bastante grandes, lo que puede ser una sobrecarga en las comunicaciones.

Al final del día, tendrá que tomar algunas decisiones en función de los riesgos que esté preparado para asumir. Personalmente, para sistemas razonablemente seguros, creo que preferiría utilizar un almacén de datos NoSQL de alto rendimiento y gastos generales para la mayoría de los casos.