Autenticación para Desarrollo Local
Esta guía cubre cómo funciona la autenticación en el entorno de desarrollo local, incluyendo la configuración de Keycloak y los procedimientos de inicio de sesión.
Configuración de Keycloak
Keycloak se ejecuta en http://localhost:8081 y se configura automáticamente con importaciones de realm cuando ejecutas make start-deps.
Consola de Administración de Keycloak
- URL: http://localhost:8081
- Nombre de usuario:
admin - Contraseña:
admin
Realms
| Realm | Propósito | Usado por |
|---|---|---|
internal | Usuarios administrativos | Panel de Administración |
customer | Clientes del banco | Clientes externos de clientes, API cliente-servidor |
Las definiciones de realm se almacenan en dev/keycloak/ y se importan automáticamente al iniciar.
Inicio de Sesión en el Panel de Administración
- Navega a http://admin.localhost:4455
- Serás redirigido a Keycloak
- Inicia sesión con: admin@galoy.io
- El panel de administración utiliza el realm
internalde Keycloak con OIDC Code Flow
Inicio de Sesión de la API de Cliente
El banco ya no proporciona un frontend web orientado al cliente dentro del repositorio. El servidor de clientes (puerto 5254) está expuesto en http://app.localhost:4455/graphql para:
- Clientes de clientes externos que gestionan su propio inicio de sesión OIDC contra el realm
customerde Keycloak. El cliente de referencia eslana-mobile-demo— si cambias el realmcustomer, el esquema del servidor de clientes o la ruta de Oathkeeperapp.localhost, verifica que esa demostración siga funcionando. - Pruebas Bats, que utilizan el flujo de concesión directa de desarrollo (contraseña) para obtener un token de acceso de Keycloak — consulta
get_customer_access_tokenenbats/helpers.bash.
Flujo de Autenticación
Cómo Funciona Oathkeeper
Oathkeeper se encuentra en el puerto 4455 y maneja toda la autenticación:
- Recibe solicitudes entrantes con tokens JWT Bearer
- Valida la firma JWT contra el endpoint JWKS de Keycloak
- Emite un JWT interno con audiencia específica de ruta y sujeto de usuario
- Redirige la solicitud al servicio upstream apropiado (admin-server o customer-server)
Los servidores backend solo aceptan JWT internos de Oathkeeper — verifican usando el JWKS de Oathkeeper y comprueban la declaración de audiencia.
Duración de Tokens (Desarrollo)
| Token | Duración |
|---|---|
| Token de acceso | 5 minutos |
| Token de actualización | 30 minutos |
| Sesión | 8 horas |