Autenticación OAuth - Secretos compartidos

El concepto de proxy deja la cuestión de la autenticación en tus manos. Como saben, la idea básica es que cree un servicio basado en servidor que sea una fachada para comunicarse con Flickr. Las aplicaciones UWP se comunican solo con su servicio web, que a su vez guarda sus secretos y los usa para comunicarse con Flickr, devolviendo solo los resultados al usuario final, sin exponerlos nunca.

Este modelo deja la cuestión de la autenticación del usuario final en tus manos. Puede crear un mecanismo que obligue a los usuarios de su aplicación UWP a autenticarse individualmente con su servicio web antes de comunicarse con Flickr, o puede permitirles que accedan a su servicio web no autenticado.

Sin embargo, aunque no estén autenticados, este modelo le brinda varias ventajas críticas.

1. Puede supervisar el acceso al servicio. Si los secretos están incrustados en la aplicación, como ha señalado, un usuario malintencionado puede eliminarlos y abusarlos, y nunca sabrá la diferencia y no tendrá la capacidad de intervenir. Si las solicitudes deben pasar por un servicio que usted controla, tiene la capacidad de detectar patrones potencialmente abusivos y, al menos, saber qué está sucediendo, y es de esperar que tenga la capacidad de mitigar el abuso al identificar y bloquear a los clientes infractores.

2. Si hay problemas con las credenciales, como que están bloqueadas o caducan y deben cambiarse, puede actualizarlas en el servidor sin tener que enviar actualizaciones a cada cliente. En el modelo actual, si las credenciales dejan de ser válidas por algún motivo, todos sus clientes se rompen hasta que pueda publicar una actualización con nuevos secretos y cada cliente la instale. En este modelo, los clientes solo están rotos hasta que actualice los secretos del servicio y luego, mágicamente, vuelvan a funcionar.

Para agregar a la excelente respuesta de Xander con respecto al proxy, aquí hay algunos enfoques alternativos comunes sin ningún orden en particular:

1. Haga que cada cliente genere sus propias claves API (client_id / client_secret) para el servicio y las cargue en la aplicación. Esto podría implicar una reducción de la facilidad de uso según el procedimiento de configuración del proveedor de la API.
2. Use el flujo de "contraseña", donde su aplicación usa las credenciales de usuario reales para obtener un token. Algunos proveedores de OAuth implementan este flujo sin autenticación de cliente para permitir clientes gruesos donde este flujo suele ser más aceptable.
3. Obtenga la clave API en línea en el inicio. Esto no es muy seguro (el usuario puede leer la clave de la memoria) pero es un término medio entre tener las claves codificadas e implementar su propio proxy. Permite la revocación / renovación / rotación de claves según sea necesario

La opción preferida sería, por supuesto, el proxy, pero cada aplicación tiene diferentes necesidades y limitaciones, y algunas de las alternativas pueden funcionar donde otras no.

Si lo comprendo correctamente, ¿desea proporcionar alguna información privada para una aplicación que creó? Supongo que este es el caso.

La codificación de cualquier información nunca es una buena práctica, a menos que sea el número de versión de la aplicación. Para las aplicaciones web, es común inyectar la configuración a través del entorno. Simplemente configure las variables de ENV como se puede hacer tanto en Windows como en Unix. Esto también le permite cambiar la configuración por servidor / host.

Algunos marcos proporcionan un archivo de configuración especial para tales configuraciones. Este archivo se excluye de git / version control y lo creas por servidor. Aquí también se almacena la configuración de la base de datos.