Social Login + API REST asegurada por OAuth2

Question

Social Login + API REST asegurada por OAuth2

#1 de Edward Barnard (1 votos)

11

Estoy implementando el inicio de sesión social con Facebook, Twitter y Google+ en nuestra API REST asegurada por OAuth2 (asegurada con spring-security-oauth ). Me gustaría asegurarme de que el siguiente flujo sea seguro y que no esté introduciendo ningún agujero de seguridad.

Overview

Hay una API REST y tres tipos de aplicaciones cliente: web, iOS y Android. La comunicación entre la API y las aplicaciones cliente se realiza a través de HTTPS.

Flow

Las aplicaciones cliente inician el flujo de inicio de sesión social a través del navegador o las aplicaciones nativas, y hacen que todo el "baile de OAuth". Obtienen una ID de usuario y un token de acceso correspondiente a esta ID de usuario.
Las aplicaciones cliente envían el ID de usuario y el token de acceso a la API REST como parámetros POST a nuestro punto final de token OAuth2 especificando un grant_type personalizado (ya sea facebook , twitter o google ).
La API REST se pone en contacto con la red social correspondiente y valida que
- El token de acceso está activo.
- El token de acceso se generó para el usuario especificado y para nuestra aplicación.
Si se cumplen las condiciones anteriores, tomamos de nuestra base de datos al usuario con la ID externa especificada y generamos nuestro propio token de acceso que se puede usar en otras solicitudes. El token de acceso se nunca se guarda en nuestra base de datos, solo el ID de usuario.

Me gustaría saber si esta es la forma correcta de implementar el inicio de sesión social en este escenario y si hay algún inconveniente en todo este flujo.

authentication oauth rest

pregunta Martin 18.02.2015 - 11:02

fuente

1 respuesta

Lea otras preguntas en las etiquetas authentication oauth rest

¿Por qué IE11 se niega a habilitar el almacenamiento en caché de navegación trasera para HTTPS? ¿Cómo consent.exe sabe qué mostrar?

score 1 · Answer 1

Su flujo se ve correcto como se indica, pero hay dificultades. Déjame explicarte.

Primero está la distinción entre "autenticación" y "autorización". El inicio de sesión social se enfoca en la autenticación: en lugar de iniciar sesión con el usuario / contraseña de tu aplicación (o lo que sea), estás permitiendo que tu usuario ya haya iniciado sesión con Google, Twitter o Facebook.

Una vez que su usuario haya iniciado sesión (por cualquier medio), SU aplicación decide qué está autorizado a hacer este usuario. Podemos olvidar que llegamos aquí a través de OAuth 2 (inicio de sesión social) en lugar del inicio de sesión normal del sitio. Ese flujo se ve bien.

¿Dónde está el problema de seguridad? En ese "baile OAuth 2" que es su paso 1, asegúrese de seguir los documentos actuales proporcionados por Google, Twitter y / o Facebook. NO exponga la clave API secreta de su aplicación al lado del cliente (navegador o aplicación nativa). En otras palabras, parte del baile debe hacerse desde el lado del servidor. Es muy fácil equivocarse, y ESO es el escollo.

Hay otra forma de ver esto. Su aplicación podría elegir actuar como un cliente OAuth 2. El token proporciona no solo autenticación, sino también autorización. El token le dice a su aplicación lo que este usuario puede y no puede hacer en su aplicación. Este es el caso de uso clásico de OAuth: una aplicación de terceros está autorizada para realizar alguna tarea (como obtener e imprimir fotos) sin tener las credenciales de inicio de sesión del usuario.

Al trabajar con OAuth 2, puede evitar muchos escollos prestando especial atención a la distinción entre autorización y autenticación. El OP hace correctamente esta distinción.