¿Cómo se autentica un usuario en el servidor B si ya está autenticado en el servidor A a través de OAuth2?

Question

¿Cómo se autentica un usuario en el servidor B si ya está autenticado en el servidor A a través de OAuth2?

#1 de Bartosz Rosa (0 votos)

1

Digamos que tengo el servidor A (un servidor web). Los usuarios inicialmente usan un proveedor externo como Google para autenticarse en ese servidor. Se crea una entrada en mi base de datos que indica que este usuario ha iniciado sesión antes y ha confirmado su cuenta. Ahora tienen acceso a recursos tales como un foro disponible desde el servidor web (por lo que esencialmente creamos una cuenta local para ellos).

Ahora, el usuario quiere autenticarse en el servidor B (un servidor de juegos). Se accede al servidor B a través de una aplicación de escritorio (cliente del juego) a través de TCP. Además, tenemos un servidor de puerta C que manejará las solicitudes iniciales de los clientes de escritorio antes de poder conectarse al servidor B.

La entrada creada para ese usuario anteriormente, se requiere para acceder al servidor B y / o C. Por lo tanto, la aplicación de escritorio debe abrir un navegador para autenticar a nuestro usuario en el servidor A.

¿Cuál es el flujo general requerido para implementar dicho sistema? Mi punto de confusión es que incluso si el servidor C sabe que el usuario está autenticado (al intercambiar tokens de acceso con el servidor A), ¿qué información pasamos al cliente de escritorio y al servidor B para que cuando el cliente se desconecte del servidor C, pueda estar seguro de que el servidor ¿B no rechazará su intento de conexión (asumiendo que la solicitud es legítima)?

authentication oauth2 webserver server

pregunta Alluring Topaz 20.10.2017 - 03:48

fuente

1 respuesta

Lea otras preguntas en las etiquetas authentication oauth2 webserver server

Identificar la escalada de privilegios en los registros OSSEC [cerrado] ¿Cómo descifrar TLS en WireShark si puedo enganchar las llamadas a la API de cifrado de la aplicación?

score 0 · Answer 1

Primero definiría todos los roles de todos los nodos que tiene. Mirando su arquitectura, pretendería que el Servidor gate (C) actúa como una puerta de enlace de la API de autorización, que es responsable de administrar los tokens necesarios para toda la autenticación y autorización. WebServer (A) y GameSever (B) son los recursos que requieren el acceso de un usuario autorizado (utilizando el token de acceso OAuth2 u otro JWT)

Definiría el flujo de esta manera:

El usuario abre el escritorio del cliente, que le indica que inicie sesión con Google. cuenta.
Las respuestas de Google con el token de identidad (es decir, el token JWT) y el cliente de escritorio se envían al Servidor Gate (C) con la información de su client_id y el recurso al que desea tener acceso (en forma de ámbitos, es decir, game_server)
El servidor de la puerta de la API de autorización (C) toma el token de identidad y, en nombre de este, crea un token de acceso (u otro token de autorización en forma de JWT) y lo envía al escritorio del cliente, que lo guarda de forma segura.
En cada llamada a Game Server (B) Client Desktop envía el El token de autorización y el servidor del juego comprueban que para autorizar el solicitud.

Lo importante aquí es que debe almacenar el token de autorización de forma segura en el lado del cliente. Esto no es fácil, así que recomendaría usar algo como tokens de referencia. En esta solución, después de que Game Server (B) obtenga el token de autorización, debe enviarlo a la API de autorización para obtener el contenido del token (notificaciones). Por lo tanto, en este caso, cada solicitud de Client Desktop a Game Server (B) da como resultado una solicitud adicional de Game Server (B) a la API de autorización (C).