¿Necesito OAuth para pasar una clave API de un servicio (ahora se pasa a través de copiar y pegar)?

4

Tengo una aplicación web, por ejemplo, http://web.app/ . Es local para cada usuario y es accesible sin autorización. Utiliza una API de un servicio https://service.app/ . El usuario puede iniciar sesión en él y ver su clave API. El usuario simplemente lo copia y lo pega del servicio a la aplicación y hay una intención de hacerlo un poco más fácil.

La primera idea es usar OAuth, pero está un poco complicada. Solo necesito pasar una clave y no necesito asegurarme de que sea correcta . Si un usuario pasa una clave incorrecta, los servicios simplemente no funcionarán.

La segunda idea es pasarla a través de una solicitud posterior. Web.app tiene un enlace a https://service.app/getapikey/ con el botón "Pasar la clave", hace una solicitud posterior a http://web.app/saveapikey/ , por lo que la aplicación web obtiene la clave.

¿Es una buena práctica no usar OAuth para tal propósito? ¿Hay algo mejor?

    
pregunta shukshin.ivan 24.01.2017 - 16:57
fuente

2 respuestas

2

Debes considerar varios factores aquí. Espero que su clave API tenga un tiempo de expiración? Incluso si lo hace, es vulnerable a un ataque de repetición si un adversario se apodera de su solicitud HTTPS. Como remedio, puede introducir una marca de tiempo o un contador a su solicitud.

Ataques de repetición de contador

Se puede agregar una marca de tiempo al mensaje y cifrarse junto con el resto del contenido del mensaje. El servicio puede recupera la marca de tiempo después de descifrar el mensaje y falla la solicitud si la marca de tiempo es demasiado antigua para el umbral eso ya está acordado. Esto reduce la ventana de oportunidad para reproducir una solicitud. La desventaja de este enfoque es que tanto el servidor como el cliente deben estar sincronizados con el tiempo.

Una alternativa a una marca de tiempo es un contador. Con un contador, no necesita preocuparse por el sesgo entre los relojes. Sin embargo, los clientes deben implementar un contador para garantizar que el recuento enviado en una solicitud sea mayor que el recuento en la solicitud anterior al menos en uno, y el El servidor debe mantener un registro del último contador recibido. Por supuesto, el mensaje debe ser firmado para que un usuario malintencionado no incrementa el contador y repite el resto de la solicitud.

Código de autenticación de mensaje basado en hash para contrarrestar el ataque MITM

El mecanismo primario para garantizar la integridad de los datos de los mensajes es un Código de autenticación de mensajes basado en Hash (HMAC). HMAC es solo una pieza de datos creados a través de un algoritmo de hash criptográfico y una clave secreta compartida. Sin embargo, si el mensaje debe cifrarse por confidencialidad, puede agregar fácilmente esa funcionalidad utilizando la misma clave privada que usamos para HMAC o puede introducir una nueva clave específicamente para el cifrado. Cuando un usuario envía una solicitud, debe preocuparse por los siguientes tres parámetros importantes.

  1. La clave pública, que es la clave asociada con el usuario
  2. El contador
  3. La marca de tiempo

Además de los parámetros, la solicitud incluye una firma que garantiza que ninguno de los parámetros sea manipulado. Es posible crear la firma basándose no solo en los tres parámetros, sino también en todo el cuerpo. de la solicitud si el objetivo es asegurarse de que no se modifique nada en la solicitud. Para asegurarnos de que nadie manipule los parámetros, podemos incluir un HMAC-SHA256 de los tres valores más el solicitar URI y método HTTP.

Puedes introducir los siguientes 4 atributos en tu encabezado.

X-KEY

Esta es tu clave API

X-Signature

Si el valor enviado por la aplicación cliente en la X-Signature coincide con el HMAC-SHA256 del Los valores de X-KEY, X-Counter, X-Stamp, URI de solicitud y el método HTTP, podemos concluir con seguridad que nada fue alterado en tránsito.

X-Stamp

Se comparan el valor enviado por el cliente y la hora de UNIX de la hora actual. Si el el sesgo entre estos dos está dentro del límite de tolerancia permitido, la solicitud no es una repetición. La hora de UNIX es el número de segundos transcurridos desde la medianoche del 1 de enero de 1970 Coordinado Tiempo Universal (UTC).

X-Counter

Si el valor enviado por el cliente es mayor que el último contador recibido en el registro mantenido por El servidor, la solicitud no es una repetición. Aunque utilizo tanto la marca de tiempo como el contador en el En el ejemplo de implementación de este capítulo, uno suele ser suficientemente bueno, dependiendo de su necesariamente. Si los tiempos del reloj están razonablemente sincronizados, una marca de tiempo es el mejor enfoque porque no hay gastos generales en términos de almacenar el contador en el lado de la API web o incrementarlo en el lado del cliente.

conclusión

Es mejor utilizar un marco de trabajo ya probado en batalla como OAuth para satisfacer sus necesidades. Pero si piensa que es demasiado complejo, debe considerar las cosas que se explican en esta respuesta.

    
respondido por el user3496510 27.01.2017 - 00:49
fuente
0

Puede cifrar la clave, luego usar base64_encode en ella y publicarla. O puedes enviarlo a través de rizo.

La clave se puede cifrar o descifrar a través de más de una manera y siempre es más fácil manejar una clave / paso cifrado con codificación de base 64 para guardarlo o transportarlo.

Si se trata de una red local y necesita usarla de una estación a otra, entonces es una buena idea hacer un rizo haciendo que las estaciones sean IP estáticas (LOCAL).

De lo contrario, si lo usa en una máquina, use la sesión php para transferir la clave

    
respondido por el Talal 27.01.2017 - 00:15
fuente

Lea otras preguntas en las etiquetas