security - redirección - uri de redireccionamiento autorizados

¿Cómo puede evitar que las aplicaciones cliente arbitrarias usen su API web anónima? (4)

La autenticación no previene el abuso de sus API tampoco. Siempre que el cliente pueda autenticarse correctamente con su sistema, puede usar cualquier cliente que elija. Solo el caso en el que el cliente y el servidor son seguros y la conexión segura puede evitar el abuso.

Si el problema es el abuso, entonces una simple solución de estrangulamiento puede ser adecuada.

Disculpas si esto ya se ha preguntado y respondido; He buscado mucho pero no he encontrado exactamente lo que estoy preguntando.

Supongamos que mi aplicación web en http://example.com/ utiliza una API web privada e indocumentada en http://api.example.com/ para buscar datos, por ejemplo, a través de XHR o JSONP.
Supongamos también que esta aplicación web es anónima, no requiere el inicio de sesión del usuario.
Como hay comunicación entre el cliente y el servidor, cualquiera puede abrir Fiddler, etc. para ver la solicitud y respuesta exactas, sin mencionar inspeccionar el código JS del lado del cliente.

En un caso como este, ¿cómo puedes evitar que alguien use tu API en una aplicación cliente no web ? Por ejemplo, una aplicación de iPhone o del lado del servidor.

A mi entender, el punto # 2 elimina la opción de algo como OAuth, y el punto # 3 elimina la opción de, por ejemplo, claves API o incluso SSL.

He pensado en cosas como los tokens basados en el tiempo o las sales secretas que se inyectan en la página en la primera carga, pero una aplicación de iPhone podría simplemente cargar su página web en secreto antes de realizar solicitudes de API.

Entonces, ¿hay alguna forma además de la simple ofuscación, la seguridad a través de la oscuridad?

En caso de que todo sea demasiado abstracto, aquí hay un ejemplo simple:

Google.com obtiene sus datos de autocompletar a través de una API privada e indocumentada, pero abierta en la web. ¿Qué me impide usarlo en mi aplicación de iPhone?

No puede evitar que las personas copien su código de cliente o que reproduzcan el tráfico de la red.

Gracias a la misma política de origen , otras aplicaciones web no pueden acceder a su API desde el cliente. Tendrán que enviar un proxy de sus solicitudes a través del servidor, lo que significa que estas solicitudes provendrán de un puñado de direcciones IP identificadas con facilidad, que puede incluir temporalmente en la lista negra.

En cuanto a las aplicaciones de escritorio y móviles, no hay mucho que puedas hacer. Mi consejo es que no te preocupes por ellos hasta que sean un problema.

Dicho eso, no está de más estar preparado. Si desea evitar costosas batallas legales, una cosa que puede hacer es cambiar sus firmas de método API de vez en cuando. Las aplicaciones de lixiviación se pueden arreglar, pero su reputación disminuirá constantemente.

Si su cliente tiene un código oculto para fisgones, ¿no podría hacer lo que sugirió, usar sales, dirección IP y valores basados en tiempo, encriptarlos y luego hacer lo mismo en el servidor? Esto es básicamente lo que hace mod_auth_tkt, y funciona bien. ¿O eso constituiría autenticación?

Sin una clave API o alguna forma de autorización, luchará en una batalla perdida tratando de mantener a clientes no autorizados fuera de su servicio.

Puedes olfatear varias cosas, pero la verdad es que la mayoría son fáciles de falsificar.

¿Controlas el otro servicio web? Además, si su aplicación web ( http://example.com/ ) accede a la API ( http://api.example.com/ ) a través de XHR o JSONP, ¿podría proxy los datos en su servidor utilizando una biblioteca como CURAR para obtener los datos, y luego ponerlos a disposición en su sitio. A continuación, puede controlar el acceso a él de la forma que mejor le parezca.