security - servidor - Cómo mantener las credenciales de los clientes confidenciales, al utilizar el tipo de subvención Credenciales de contraseña de propietario de recursos de OAuth2

oauth2 vs jwt español

Question

Estamos construyendo un servicio de descanso y queremos usar OAauth 2 para autorización. El borrador actual (v2-16 del 19 de mayo) describe cuatro tipos de subvenciones . 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 del propietario del recurso
4. Credenciales del cliente

Parece que necesitamos apoyar a los cuatro, 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 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 e inicie sesión. También queremos usar 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.

Entonces mis preguntas son:

1. ¿Crees que he entendido correctamente el propósito de los diferentes tipos de subvenciones?
2. ¿Cómo puede mantener sus credenciales de cliente en forma confidencial? 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 el secreto de su cliente, ¿qué impide que otra aplicación se haga pasar por su aplicación utilizando el mismo mecanismo de autorización y la identificación de su cliente?

En resumen, queremos poder 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

Estoy enfrentando 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.

Solo para dirigir las respuestas en cada uno de sus puntos:

1. Sigo releyendo diferentes borradores de la especificación para ver si algo ha cambiado, y estoy enfocado principalmente en la sección de Credenciales de la contraseña del propietario del recurso, pero creo que estás en lo cierto. 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 puedas 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 de 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, ya 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 API para tratar de detectar abusos, en cuyo punto puede invalidar una clave 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 usar 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.