¿Debe el cliente tener acceso al token de acceso de la API de terceros?

Question

¿Debe el cliente tener acceso al token de acceso de la API de terceros?

#1 de Chayan Ghosh (0 votos)

0

Estoy tratando de determinar si usar un Token provisto por un servicio de Terceros directamente, O emitir mi propio Token personalizado y almacenar el lado del servidor de Terceros de Token.

Flujo de autenticación

El usuario autentica su identidad a través de un tercero (inicio de sesión en redes sociales / gestión de identidad). Para ello, ingresan su nombre de usuario y contraseña en la página de inicio de sesión del tercero (expuesta como una vista web en la aplicación de cliente), y el tercero devuelve a la aplicación de cliente un "token de autorización".
El cliente envía el 'Token de autorización' a mi servidor, que en combinación con una 'Clave de aplicación secreta' (proporcionada por un tercero) permite al servidor intercambiar el 'Token de autorización' del usuario por un 'Token de acceso' (el token que realmente necesito para hacer llamadas a la API en nombre del usuario). Esto sucede en el lado del servidor y me permite mantener en secreto mi 'clave de aplicación secreta' y fuera del alcance del cliente.
En este punto, no estoy seguro de si ...
1. Envíe el 'token de acceso' de terceros al cliente para que pueda incluirlo en todas las llamadas futuras al servidor que luego llamará a la API de terceros, O
2. Envíe un token JWT personalizado al cliente, almacenando el 'token de acceso' del tercero en el servidor para cada usuario.

Tengo la intención de hacer todas las llamadas futuras al lado del servidor API de terceros, sin embargo, mis preocupaciones con cada opción son:

Si el cliente tiene su token de acceso para el servicio de terceros, aunque solo permite el acceso a los datos a los que tiene acceso su cuenta, significa que podrían realizar llamadas API adicionales contra los límites de llamadas de mi aplicación.
Si el servidor mantiene este token de acceso de terceros (nunca lo envía al cliente), crea un recurso que es confidencial y debe almacenarse y protegerse. Creo que sería más seguro tener solo acceso temporal al token de acceso cuando sea necesario.

¿Cuál es la forma preferida de manejar esto?

authentication session-management

pregunta Z-Mehn 30.08.2018 - 12:40

fuente

1 respuesta

Lea otras preguntas en las etiquetas authentication session-management

¿Los esquemas de autenticación REST que exponen la clave compartida están protegidos contra proxies inversos que actúan como agentes de usuario incorrectos? Acción de formulario no especificada - contaminación de parámetros HTTP

score 0 · Accepted Answer

el marco oAuth 2 no regula este aspecto, por lo que técnicamente cualquiera de los dos enfoques está bien. Sin embargo, lo que generalmente se sigue es aquel en el que el servidor mantiene el token de acceso, junto con el token de actualización (en caso de acceso sin conexión, por ejemplo, en el marco de Google oAuth).

Cuando está utilizando una autenticación de terceros, la está utilizando como un IDP (proveedor de identidad) para poder adjuntar la identidad al usuario. Además de eso, según lo restringido por los ámbitos del token de acceso, puede acceder a algunos servicios adicionales proporcionados por el servidor de recursos de terceros. Después de esto, cualquier interacción que ocurra entre el cliente y su servidor debe ser administrada por la sesión de su propia aplicación. No debe usar el token de acceso como su token de sesión en su aplicación.

Para comentar sobre el inconveniente con este enfoque como comentó:

Si el servidor mantiene este token de acceso de terceros (nunca lo envía al cliente), crea un recurso que es confidencial y debe almacenarse y protegerse. Creo que sería más seguro tener solo acceso temporal al token de acceso cuando sea necesario.

Incluso si el token de acceso se devuelve a su cliente, aún tendría que asegurarse de que esté almacenado en el cliente de forma segura. Y es más fácil proporcionar esa seguridad en el servidor que en el cliente.

Envíe el 'token de acceso' de terceros al cliente para que se pueda incluir en todas las llamadas futuras al servidor que luego llamará a la API de terceros,

Esto parece no ser una muy buena idea por la otra razón que es completamente redundante en este caso para enrutar la solicitud a través de su servidor. Si el cliente tiene el token de acceso (que generalmente es un token de portador), puede comunicarse directamente con el servidor de recursos de terceros. A menos que, por supuesto, el servidor de terceros restrinja el acceso en función de la inclusión en la lista blanca de IP u otros medios. De nuevo, en ese caso, es mejor tener su propia sesión personalizada entre su cliente y el servidor y dejar que el servidor hable con el servidor de recursos utilizando el token de acceso que guarda consigo mismo.