javascript - tienes - oauth login google

Flujo adecuado de OAuth2 para clientes públicos de primera línea

Question

Soy un lector habitual aquí en desbordamiento de pila, pero esta es mi primera pregunta.

Estoy desarrollando un servidor de autorización usando las especificaciones OAuth2. Y me quedé atascado con la forma de garantizar la autenticidad del cliente de primera mano mientras uso el flujo de contraseñas. Leí muchos foros y esto es lo que obtuve:

1. Clientes de una sola página de Javascript

   Esta publicación de blog de Alex Bilbie, afirma que para evitar el problema de client_secret deberíamos simplemente:

   Es sencillo; Proxy todas sus llamadas API a través de un componente del servidor delgado. Este componente (vamos a llamarlo proxy a partir de ahora) autenticará las solicitudes ajax de la sesión del usuario. Los tokens de acceso y actualización se pueden almacenar en una forma cifrada en una cookie que solo el proxy puede descifrar. Las credenciales del cliente de la aplicación también estarán codificadas en el proxy para que no sean accesibles públicamente.

   Pero ahora este proxy puede ser accedido por alguien que se hace pasar por mi aplicación angular. Y luego me encontré con esta publicación de Andy Fielder: ¿Qué tan seguro es el Flujo de contraseña del propietario de OAuth2 Resourc para aplicaciones de una sola página ? Básicamente dice que confíe en CORS para evitar hacerse pasar por clientes de JS.

   ¿Es una buena idea utilizar ambos enfoques para proteger mi aplicación JS?

2. Aplicaciones nativas (escritorio y móvil)

   En el caso de las aplicaciones móviles, solo encontré casos para el Código de autorización y Flujos implícitos. Esto no es lo que quiero, ya que los redireccionamientos comprometerán la experiencia del usuario. Entonces mis pensamientos sobre esto son:

   Utilizaré el flujo de ROP y luego registraré el cliente con un client_id generado para esta instalación en particular y lo conectaré a la cuenta de usuario, recibiendo access_token y un client_secret como respuesta. Cualquier otra solicitud de token realizada por este cliente DEBE llevar estas credenciales (ya que client_id es específico para la instalación, podré verificar si este cliente ya está autenticado). De esta forma, si alguien usa una credencial para hacerse pasar por un cliente, o incluso registra un cliente falso, puedo tomar medidas para revocar el acceso del usuario y del cliente.

Sé que esto puede ser un pensamiento excesivo, y también sé que algo de esto no evita nada. Siento que es mi trabajo proteger mi API tanto como pueda.

¡Realmente apreciaría tus pensamientos sobre esto! ¿Realmente estoy pensando demasiado? ¿Debo usar el concepto de ''cliente público'' y continuar?

¡Gracias a todos y feliz codificación!

Answer 1

En primer lugar, este problema no es una prioridad común porque la mayoría de las aplicaciones se desarrollan primero con el sitio web y luego con el API. Esta es probablemente la razón porque nadie sabe cómo tratar a los primeros clientes con oauth2, porque todos han desarrollado otras formas de hacerlo y se necesita oauth2 solo para otorgar acceso de usuario a aplicaciones de terceros.

Incluso si ha desarrollado el servidor de autorización de oauth2 solo para sus primeras aplicaciones de clientes (pensando en un único mecanismo de autenticación en lugar de desarrollar muchos), debe intentar desarrollar el código de autorización o los tipos de concesión implícitos. Te darás cuenta de que necesitas una forma de comprobar qué usuario está realmente conectado .

Los dos métodos comunes son:

• sesión de usuario (basada en Cookies)
• acceso de usuario de localStorage (javascript basado)

De cualquier forma, debe verificar la seguridad de su aplicación, la sesión del usuario es vulnerable a CSRF, localStorage es vulnerable a XSS. Hay muchos artículos sobre cómo proteger su sitio web contra cualquiera, así que no voy a sugerir nada aquí, solo necesita saber que existen.

Ahora que eliges tu método de autenticación, podemos comenzar a considerar:

Javascript aplicaciones de una sola página

1. Apoderado
   Tener un proxy que filtra todas las solicitudes en mi opinión es como tener una puerta con las claves siempre insertadas. Es inútil incluso construir la puerta. Sin embargo, para la autenticación basada en sesiones, es la única forma de hacerlo. Permitir la autenticación de sesión en su Rest API abrirá problemas de seguridad CSRF, por lo que debe tener una capa de proxy que obtenga la sesión del usuario, recupere el token de acceso de la sesión y realice la solicitud a la API Rest agregando el encabezado Authorization .

2. CORS
   Con este método, debe almacenar el token de acceso de usuario en localStorage, ya que el token se recupera directamente del cliente Js.
   Al usar CORS, está seguro de que otros sitios web no pueden hacer solicitudes a su Rest API desde un navegador. Pero su primer cliente debe ser público (es decir, no tiene un client_secret ).

Aplicaciones nativas (escritorio y móvil)

En mi primera aplicación intenté usar el mismo mecanismo que sugieres para asegurar el flujo de autenticación. Sin embargo, ese tipo de mecanismo requiere que identifiques cada cliente de usuario de una manera única. Esto no es posible en iOS por razones de privacidad y con cierta probabilidad se denegará en las futuras versiones de Android. Por lo tanto, debe confiar en un cliente público y agregar solo client_id en su código de aplicación nativo.

Esto significa que su cliente de aplicación nativa / su cliente js puede ser despersonalizado.
Sí, y no hay forma de evitar esto con el tipo de concesión de credenciales de contraseña del propietario del recurso oAuth2 .

La razón principal de esto es porque oAuth2 no es para autenticación, solo para la autorización de terceros, y ese tipo de concesión se agregó solo para aplicaciones de terceros específicas de confianza lo suficiente como para usar directamente la contraseña del usuario . Puede leer más sobre este argumento aquí y aquí .

Al final

Aún necesita una forma de autorizar a su usuario, y creo que lo mejor que puede lograr con oAuth2 es lo que hizo Auth0 . Esencialmente, este Saas administra a sus usuarios con un servidor oAuth2 + conexión OpenID, por lo que siempre está administrando a sus usuarios como si fuera una aplicación de terceros y todo funciona bien.

De hecho, puede ver en esta página que para aplicaciones móviles sugieren utilizar un formulario de inicio de sesión basado en el navegador, porque el nativo puede ser despersonalizado por todos los que descompilan su aplicación, pero si lo envuelve en un flujo de código de autorización funciona bien.