¿Se pueden usar las herramientas web JSON para simplificar el protocolo OAuth2 sin comprometer la seguridad?

Question

¿Se pueden usar las herramientas web JSON para simplificar el protocolo OAuth2 sin comprometer la seguridad?

#1 de Steve (1 votos)

0

He usado json webtokens para manejar la autenticación de algunos sitios web de pasatiempos en el pasado. Para mi próximo sitio, me gustaría usar OAuth2, para permitir que mi sitio se use con otros servicios.

Parece que el protocolo de código de autorización OAuth2 agrega algunos pasos adicionales (estado y código de autorización) para evitar una especie de ataque de repetición en el que un cliente es engañado para que use un token de acceso emitido a otro cliente.

¿Es ese el único propósito de emitir un código de autorización antes del intercambio de token? Si agrego información como client_id y tiempo de vencimiento en un JWT firmado y lo devuelvo como el 'código de autorización', omitiendo el paso de intercambio de token, ¿habré perdido alguna seguridad? Supongo que todas las comunicaciones se producen a través de https.

oauth2 jwt

pregunta user3125280 24.02.2017 - 09:46

fuente

1 respuesta

Lea otras preguntas en las etiquetas oauth2 jwt

Encontrar un script de Webshell en los directorios de inicio del usuario. arreglo ziptox1 de Ransomeware

score 1 · Accepted Answer

El punto del código es evitar la recopilación del token de acceso por un usuario intermedio entre el usuario y el servidor de autorización.

Una vez que el cliente tenga el código, necesita usar ese código además de su propio ID de cliente y secreto y enviarlo al servidor de autorización para obtener un token de acceso. Esto tiene la ventaja de que tanto usted como el cliente están autenticados / autorizados contra el servidor de autorización, lo que significa que el recurso protegido tiene cierta seguridad de que cada parte es quien dice ser. Una vez que el cliente tiene el token, se supone que almacena el token internamente y nunca lo libera.

La interacción entre usted y el cliente se autentica mediante su propio mecanismo (por ejemplo, una cookie de sesión), y el cliente utiliza el token de acceso que tiene internamente para llegar al recurso protegido.

La clave aquí es que el cliente está lo suficientemente protegido de que alguien tome el token porque (por ejemplo) está en un servidor web remoto en lugar de ejecutarse localmente en su computadora.

A la inversa, si el cliente finalmente revela el token al usuario, ya sea usándolo para su propia administración de sesión o si se ejecuta localmente en su propia computadora, el código no proporciona ninguna valor porque puede extraer fácilmente el ID de cliente, el secreto, el código o el token.

Agregar la identificación del cliente al token no necesariamente evita el robo del token. Solo significa que el token estaba destinado a ser utilizado a través de un cliente determinado.