Recursos · 43
OAuth y OpenID Connect: verificar una integración extremo a extremo
Separe los permisos de inicio de sesión, delegación y datos, luego pruebe las redirecciones, los tokens, las sesiones y la revocación.
Actualizado · 4 min
Lo que esta guía ayuda a lograr
- Separar identidad de autorización
- Rechazar tokens y redirecciones no deseadas
- Pruebe los rechazos con tanto cuidado como los aciertos
- Verificar eliminación de acceso tras salida o incidencia
Comprobación rápida
- ¿Qué proveedor y emisor se espera?
- ¿Está registrada la URI de redireccionamiento de forma precisa?
- ¿Se está utilizando incorrectamente un token ID como token de acceso?
- ¿Cada recurso verifica la propiedad?
- ¿Qué acceso sobrevive a la revocación?
Método paso a paso
- 1
Dibujar el flujo desplegado
Identificar cliente, navegador, servidor de autorización, API y proveedor de OIDC públicos o confidenciales. Registre dónde viajan los códigos y tokens, quién los almacena y qué roles se otorgan. Un diagrama de ventas no establece el despliegue real.
Entregable: flujo, límites de confianza y propietarios de componentes.
- 2
Verificar la transacción de inicio de sesión
Utilizar el flujo de código con PKCE adecuado al cliente. Verifique S256, vinculación de transacciones, redirecciones registradas y protección contra solicitudes falsificadas. Pruebe un URI inesperado, un verificador incorrecto, un código reproducido y un emisor inesperado. RFC 9700 separa los requisitos y recomendaciones por tipo de cliente.
Entregable: resultados de pruebas permitidos y denegados.
- 3
Validar el token correcto
La API valida su token de acceso según formato y reglas del proveedor: firma o introspección, emisor, audiencia, caducidad y permisos. El cliente OIDC valida por separado el token de identidad. Una firma válida no establece que el token pertenezca a esta API.
Entregable: contrato de validación y pruebas de audiencia y caducidad.
- 4
Comprobar permisos empresariales
Probar un objeto propiedad de otra cuenta, un rol inferior, campo privado y operación administrativa. Un alcance o una puerta de enlace autenticada no reemplaza las comprobaciones del lado del servidor en el recurso solicitado. Utilice cuentas y datos de prueba autorizados.
Entregable: rol, objeto, operación y matriz de denegación esperada.
- 5
Caducidad y revocación del ejercicio
Separación de sesión local, sesión de proveedor, token de acceso y token de actualización. Salida de prueba, pérdida de dispositivo, cambio de rol, rotación de clave de firma e interrupción del proveedor. Documente el tiempo de acceso residual en lugar de asumir que el cierre de sesión revoca todo inmediatamente.
Entregable: cronograma de eliminación de acceso y excepciones.
- 6
Observar sin exponer secretos
Referencia de transacciones de registro, decisión de validación, categoría de error y versión de configuración. Excluye códigos, tokens y secretos. Preparar el diagnóstico, el cierre de la integración y la reversión a una configuración validada; repetir las pruebas después de cambiar de proveedor.
Entregable: procedimiento operativo y comprobaciones de regresión.
Ejemplo trabajado ficticio
Situación ilustrativa
Situación ilustrativa: dos clientes utilizan un proveedor de identidad. Un token válido para el primero se presenta a la API del segundo cliente.
Decisión y pruebas esperadas
La API rechaza la audiencia incorrecta, registra un seguimiento sin token y no devuelve datos. La negación se convierte en una prueba de regresión.
Distinguir los mecanismos
| Mecanismo | Propósito | Verificación o limitación |
|---|---|---|
| OAuth 2.0 | Delegar acceso a recursos | Permisos de objetos del lado del servidor |
| Conexión OpenID | Establecer identidad mediante un token ID validado | Validación de emisor, audiencia y transacciones |
| Sesión de aplicación | Mantener el inicio de sesión de la aplicación | Caducidad, invalidación y protección de sesión |
Indicadores de gestión
| Indicador | Qué mide | Primera acción |
|---|---|---|
| Corregir denegaciones | Casos prohibidos realmente bloqueados | Arreglar cada aceptación inesperada |
| Retraso de revocación | Tiempo hasta que desaparece el acceso relevante | Consultar sesiones y tokens por separado |
| Fallos de validación | Rechazos por causa y versión | Separar ataques de errores de configuración |
Errores comunes
- Confundir autenticación con autorización
- Aceptar cualquier audiencia tras comprobar la firma
- Registro de URI de redireccionamiento amplio
- Registro de tokens para una depuración más sencilla
Preguntas frecuentes
¿PKCE reemplaza todos los controles?
No. Protege el intercambio de código en el flujo previsto; La validación del token, las redirecciones, la autorización comercial y las sesiones aún deben verificarse.
¿Un JWT es un permiso?
JWT es un formato. Los reclamos se vuelven utilizables solo después de la validación y aplicación de sus reglas API.
¿Se debe construir la validación desde cero?
Prefiere una biblioteca mantenida y documentación del proveedor, luego prueba tu configuración. Una biblioteca correcta aún puede configurarse incorrectamente.
Referencias oficiales
Las referencias respaldan el método. Adapte los controles a su contexto; no constituyen certificación. Los títulos de referencia originales y los documentos fuente pueden estar en otro idioma.
