Cómo mantener la confidencialidad de las credenciales del cliente, al utilizar el tipo de concesión de credenciales de propietario de recurso de OAuth2 tipo

Question

Estamos creando un servicio de descanso y queremos utilizar OAauth 2 para autorización. El current draft (v2-16 del 19 de mayo) describe four grant types. Son mecanismos o flujos para obtener autorización (un token de acceso).

1. código de autorización
2. subvención implícita
3. Credenciales de recursos del propietario
4. credenciales del cliente

parece que tienen que soportar las cuatro de ellos, ya que sirven para diferentes propósitos. Los primeros dos (y posiblemente el último) se pueden usar desde aplicaciones de terceros que necesitan acceso a la API. El código de autorización es la forma estándar de autorizar una aplicación web que tiene la suerte de residir en un servidor seguro, mientras que el flujo implícito de concesión sería la opción para una aplicación cliente que no puede mantener sus credenciales de manera confidencial (por ejemplo, móvil/computadora de escritorio aplicación, cliente de JavaScript, etc.).
Queremos utilizar el tercer mecanismo para proporcionar una mejor experiencia de usuario en dispositivos móviles: en lugar de llevar al usuario a un cuadro de diálogo de inicio de sesión en un navegador web, el usuario simplemente ingresará su nombre de usuario y contraseña directamente en la aplicación y el inicio de sesión. También deseamos utilizar el tipo de concesión de credenciales de cliente para obtener un token de acceso que se puede usar para ver datos públicos, no asociados con ningún usuario. En este caso, esto no es tanto una autorización, sino más bien algo similar a una clave API que utilizamos para dar acceso solo a las aplicaciones que se han registrado con nosotros, lo que nos da la opción de revocar el acceso si es necesario.

Así que mis preguntas son:

1. ¿Cree que he entendido el propósito de los diferentes tipos de subvenciones correctamente?
2. ¿Cómo puede mantener la confidencialidad de sus credenciales de cliente? En el tercer y cuarto caso, necesitamos tener la identificación del cliente y el secreto del cliente en algún lugar del cliente, lo cual no parece una buena idea.
3. Incluso si usa el tipo de concesión implícita y no expone su secreto de cliente, ¿qué impide que otra aplicación suplante su aplicación utilizando el mismo mecanismo de autorización y su ID de cliente?

En resumen, queremos ser capaces de utilizar las credenciales del cliente y el flujo de credenciales del propietario del recurso desde una aplicación cliente. Ambos flujos requieren que almacene el secreto del cliente de alguna manera, pero el cliente es una aplicación móvil o de JavaScript, por lo que pueden ser robados fácilmente.

Answer 1

Tengo problemas similares, y también soy relativamente nuevo en OAuth. Implementé "Credenciales de contraseñas de propietario de recursos" en nuestra API para que las use nuestra aplicación móvil oficial: los flujos web parecen ser tan horribles de utilizar en una plataforma móvil, y una vez que el usuario instala una aplicación y confía en ella que es nuestra aplicación oficial, deben sentirse cómodos escribiendo nombre de usuario/contraseña directamente en la aplicación.

El problema es que, como usted señala, no hay forma de que mi servidor API verifique de forma segura el client_id de la aplicación. Si incluyo un client_secret en el código/paquete de la aplicación, queda expuesto a cualquier persona que instale la aplicación, por lo que requerir un client_secret no haría que el proceso sea más seguro. Básicamente, cualquier otra aplicación puede suplantar mi aplicación al copiar el client_id.

Sólo para dirigir respuestas en cada uno de sus puntos:

1. sigo releyendo diferentes borradores de la especificación para ver si algo ha cambiado, y estoy centrado principalmente en la sección Credenciales contraseña de recursos del propietario, pero Creo que tienes razón en esto. Credenciales del cliente (4) Creo que también podría ser utilizado por un servicio interno o de terceros que podría necesitar acceso a más información que simplemente "pública", como tal vez tenga análisis o algo que necesite obtener información entre todos los usuarios.

2. No creo que pueda mantener algo confidencial en el cliente.

3. Nada impide que otra persona use su ID de cliente. Este es mi problema también. Una vez que su código abandona el servidor y se instala como una aplicación o se ejecuta como Javascript en un navegador, no puede suponer que nada sea secreto.

Para nuestro sitio web, tuvimos un problema similar al que describe con el flujo de credenciales del cliente. Lo que terminé haciendo es mover la autenticación al lado del servidor. El usuario puede autenticarse utilizando nuestra aplicación web, pero el token OAuth de nuestra API se almacena en el servidor y se asocia con la sesión web del usuario. Todas las solicitudes de API que realiza el código Javascript son realmente llamadas AJAX al servidor web. Por lo tanto, el navegador no se autentica directamente con la API, sino que tiene una sesión web autenticada.

Parece que su caso de uso para credenciales de cliente es diferente, en el sentido de que está hablando de aplicaciones de terceros y solo está publicando datos públicos a través de este método. Creo que sus preocupaciones son válidas (cualquiera puede robar y usar la clave de API de otra persona), pero si solo requiere un registro gratuito para obtener una clave de API, no veo por qué alguien realmente quisiera robar una.

Puede supervisar/analizar el uso de cada clave de API para intentar detectar el uso indebido, momento en el que puede invalidar una clave de API y darle al usuario legítimo una nueva. Esta podría ser la mejor opción, pero de ninguna manera es segura.

También podría utilizar un esquema Refresh Token para esto si quisiera bloquearlo un poco más, aunque no sé cuánto ganaría realmente. Si expiró las fichas de API expuestas a Javascript una vez al día y requería que el tercero realizara algún tipo de actualización en el servidor con un token de actualización (secreto), las fichas api robadas nunca serían válidas por más de un día. Podría alentar a los posibles ladrones simbólicos a que simplemente se registren. Pero una especie de dolor para todos los demás, por lo que no estoy seguro si esto vale la pena.