Riesgo de mantener OAuth2 client_secret en la aplicación

3

Como ejercicio, estoy desarrollando una aplicación de escritorio con la cual los usuarios necesitan iniciar sesión en un servicio web. Un caso de uso lógico para OAuth2 diría, pero estoy empezando a dudar de su utilidad. Estoy buscando autenticación de dos patas , que deja disponibles los flujos de credenciales de cliente , implícito y propietario de recursos .

Como me gustaría que los usuarios pudieran iniciar sesión directamente dentro de la aplicación (no a través de un navegador y redirigir el URI), el flujo implícito desaparece como opción. Los otros dos flujos requieren que se envíen client_id y client_secret , y he leído muchas veces que no es seguro almacenar client_secret dentro de su aplicación de escritorio.

Mi pregunta es esta: ¿cuán inseguro es esto realmente? ¿Qué tan fácil es para los adversarios descompilar las aplicaciones (de escritorio) y averiguar el client_secret ? podría considerar aceptar el riesgo, de modo que pueda usar las de OAuth2 , porque el rodar mi propio esquema de autenticación probablemente sería aún menos seguro.

P.S. Alguien mencionó que utiliza el flujo implícito y que inicia temporalmente un servidor web en localhost como redirección de URI para eludir un navegador, pero eso parece excesivo si no es inseguro. ¿Algún pensamiento?

    
pregunta Stijn Frishert 02.02.2015 - 11:29
fuente

1 respuesta

1

Consulte el proceso de OAuth para aplicaciones del lado del cliente .

Su flujo de OAuth debería verse así:

  1. El usuario inicia sesión
  2. Su API devuelve un token de acceso para ese usuario
  3. Su aplicación de escritorio almacena el token del usuario
  4. Las solicitudes futuras envían el token, y la API lo usa para autenticar al usuario

No puedes proteger de manera realista una clave secreta global en tu aplicación, ni realmente tienes que hacerlo.

    
respondido por el Joel L 02.02.2015 - 16:10
fuente

Lea otras preguntas en las etiquetas