Recomendaciones de seguridad

Para integrar de forma segura sus aplicaciones con dominios de identidad mediante OAuth, debe implantar los controles de seguridad recomendados por el estándar.

Los controles de seguridad pueden considerarse obligatorios u opcionales en función de los requisitos de confidencialidad, integridad y disponibilidad de la aplicación.

Una integración OAuth segura requiere:

Controles de seguridad implantados en todos los participantes OAuth, que incluyen el servidor de autorización (IAM), el propietario de recurso (usuario), el cliente y las aplicaciones del servidor de recursos
Confidencialidad de la información de clave: código, access_token, refresh_token, credenciales de cliente y credenciales de usuario
Autenticación de servidor establecida entre participantes de OAuth (para evitar ataques de suplantación)
Validación de información adecuada para cualquier solicitud (especialmente para tokens de acceso de token web JSON (JWT))
Uso de tokens con alcances mínimos y tiempo de espera (para reducir la exposición en caso de divulgación y para admitir la revocación del token)
Uso de los principios típicos de seguridad de la información, como el privilegio mínimo

Recursos

Para obtener más información sobre la seguridad de OAuth, acceda a los siguientes enlaces:

Nota

Le recomendamos que supervise la seguridad de forma proactiva para poder identificar rápidamente nuevas amenazas de seguridad.

Lista de comprobación de recomendaciones de seguridad

Esta página muestra las recomendaciones de seguridad más relevantes como una lista de control, para que pueda validar la seguridad de la aplicación y abordar los elementos de seguridad según sus expectativas.

Cifrado

Uso de TLS en aplicaciones de cliente y servidor de recursos

El uso de TLS con todas las aplicaciones proporciona confidencialidad en las comunicaciones entre el dominio de identidad, los propietarios de recursos, las aplicaciones cliente y las aplicaciones del servidor de recursos. Esto evita la intrusión durante la transmisión del código de autorización, los tokens de acceso, los tokens de refrescamiento, las credenciales de cliente y las credenciales de usuario, y evita los ataques de reproducción.
Establecimiento de autenticación de servidor (HTTPS con validación de CA de confianza)

La autenticación del servidor permite a los clientes, servidores de recursos y propietarios de recursos establecer la comunicación entre ellos y con un dominio de identidad después de verificar el certificado público con la CA de confianza.

Si el servidor no proporciona un certificado de confianza (proporcionado por una CA de confianza y con un nombre de host coincidente), la comunicación se considera un ataque de tipo man-in-the-middle.

La autenticación del servidor evita la suplantación de identidad, el proxy, el comando man-in-the-middle y los ataques de suplantación de identidad para capturar códigos de autorización, tokens de acceso, credenciales de cliente y credenciales de usuario.
Consideración del uso de una afirmación de confianza con dominios de identidad

Los clientes de seguridad críticos pueden utilizar una afirmación de cliente con criptografía de clave (en lugar de un secreto de cliente) para la autenticación.
Protección del URI de redirección con HTTPS y validación de CA de confianza

HTTPS y el uso de la validación de CA de confianza evita el phishing de "código" de autorización y la suplantación de sesión de usuario.

Administración

Configuración de aplicaciones siguiendo el principio de privilegio mínimo

Las aplicaciones se deben configurar en un dominio de identidad solo con los derechos mínimos necesarios para su operación.

Reducir el ámbito, los flujos, los tipos de permisos y las operaciones mejora la estrategia de seguridad y reduce el impacto de una aplicación comprometida.
Proporcione un nombre y una descripción significativos para las aplicaciones

La información de la aplicación aparece para los usuarios en Mis aplicaciones y en las páginas de consentimiento.

El uso de nombres y descripciones de aplicación significativos puede evitar que los usuarios cometan errores durante la autorización del consentimiento y también contribuye a mejorar los informes de auditoría.
Proporcionar una descripción significativa para ámbitos

La descripción del ámbito aparece en la página de consentimiento. Explicar el ámbito, que el usuario está a punto de otorgar, evita de forma comprensible que el usuario cometa errores durante la autorización y contribuye a mejorar la generación de informes de auditoría.
Evitar ámbitos proporcionados sin consentimiento

Para aprovechar la transparencia y confiar en el propietario del recurso, proporcione ámbitos sin permiso solo cuando un ámbito sea obligatorio y el usuario no pueda negarlo.
Reducción del timeout del token de acceso y uso de tokens de refrescamiento

Los dominios de identidad soportan JWT, un token de acceso que se puede validar en servidores de recursos sin comprobar el token en el dominio de identidad. Debido a esto, los tokens de acceso de larga duración no se pueden revocar fácilmente.

Para implementar la revocación oportuna, puede configurar el token de acceso con una vida útil corta y, a continuación, utilizar el token de refrescamiento para solicitar nuevos tokens de acceso. Para realizar una revocación oportuna, debe revocar el token de refrescamiento.
Rotación de los secretos de cliente de la aplicación

Para implantaciones críticas de seguridad, implante una rotación de secreto de cliente. Esto reduce el riesgo de obtener un secreto de cliente comprometido explorado.

Propietario de recurso (usuario)

Mantener informado al propietario del recurso

El uso del ámbito con consentimiento proporciona transparencia al propietario del recurso e impide que las aplicaciones soliciten ámbitos que no son necesarios.
Conocimiento del usuario

Enseñe a los usuarios a proteger sus credenciales e identificar la legitimidad del cliente, la aplicación del servidor de recursos y el dominio de identidad (especialmente cuando aparecen las páginas de autenticación y consentimiento). Esto reduce el riesgo de ataques de phishing y el compromiso de las credenciales de usuario.

Desarrollo de Aplicaciones

Protección de códigos, tokens de acceso, tokens de refrescamiento y credenciales de cliente

Las aplicaciones deben preservar la confidencialidad de los códigos, los tokens de acceso, los tokens de actualización y las credenciales de cliente. Al desarrollar la aplicación, tenga en cuenta las siguientes medidas (entre otras medidas de seguridad de la aplicación):
- No almacenar códigos (utilizar el código solo durante el tiempo de ejecución para obtener el token de acceso)
- Mantener tokens de acceso en memoria transitoria y limitar sus permisos
- Almacenar tokens de refrescamiento y credenciales de cliente en lugares seguros a los que solo puede acceder la aplicación
Protección de la URL de redirección

La URL de redirección (desde la que el dominio de identidad recupera el código de autorización) se considera un componente clave para la seguridad OAuth. Tenga cuidado al definir esta URL para evitar amenazas como la falsificación de solicitudes entre sitios y la denegación de servicio.
Leer tokens del sistema de archivos de aplicaciones nativas

Los atacantes pueden intentar obtener acceso al sistema de archivos en el dispositivo y leer los tokens de actualización mediante una aplicación maliciosa. Para reducir este riesgo, almacene secretos en un almacenamiento seguro y utilice el bloqueo del dispositivo para evitar el acceso no autorizado al dispositivo.
Implementación de controles para dispositivos clonados y robados con aplicaciones nativas

Para reducir los riesgos cuando un dispositivo con aplicaciones nativas es clonado o robado, utilice el bloqueo del dispositivo para evitar el acceso no autorizado y revocar tokens de actualización.
Validar seguridad de aplicación antes de la publicación

Pruebe la seguridad de la aplicación y su entorno de alojamiento antes de publicar la aplicación para reducir las vulnerabilidades. Los dominios de identidad no abordan las amenazas relacionadas con el alojamiento y el desarrollo de aplicaciones. Estas amenazas incluyen, entre otras, el acceso indirecto a las bases de datos y el almacenamiento de aplicaciones, el click-jacking, los scripts de sitios, la inyección de scripts/SQL y los flujos de confidencialidad de la información en la aplicación.
Aplicar privilegio mínimo durante solicitud de ámbito

Las aplicaciones cliente deben solicitar tokens que contengan solo ámbitos que posiblemente o realmente utilizarán.

El uso de urn:opc:idm:__myscopes__ scope, aunque es conveniente, puede recuperar más tokens de los que necesita la aplicación cliente.

Un token con ámbitos extensos puede aumentar el impacto de seguridad cuando un token se ve comprometido.

Consulte Ámbitos para obtener información sobre el uso del parámetro de ámbito y un token de acceso para otorgar diferentes niveles de acceso a los dominios de identidad.
Validar tokens de JWT

Al recibir un token de acceso (JWT) de cualquier parte (excepto el servidor de dominio de identidad en una solicitud directa de la aplicación), valide el JWT siguiendo el perfil de JWT para permisos de autenticación y autorización de cliente OAuth 2.0 y las RFC de JWT.

Consulte Validación de tokens para obtener más información sobre cómo validar el token.

Nota

Los servidores de recursos solo deben procesar información después de realizar toda la validación de JWT.
Recibir tokens de JWT correctamente

Las aplicaciones del servidor de recursos deben recibir el token de acceso utilizando solo la cabecera Authorization: bearer <token> para evitar amenazas relacionadas con el almacenamiento en caché de parámetros.
Implementación de TLS de 2 vías entre aplicaciones de cliente y servidor de recursos

Para las aplicaciones críticas para la seguridad, puede implementar un TLS de 2 direcciones entre las aplicaciones cliente y servidor de recursos para reducir el riesgo de ataques de denegación de servicio (DoS) y suplantación de identidad.

No escriba aplicaciones que recopilen información de autenticación directamente de los usuarios.
Prevención de Click-Jacking

Para exploradores más recientes, evite iFrames durante la autorización mediante la aplicación del uso de la cabecera X-FRAME-OPTIONS.

Para exploradores más antiguos, se pueden utilizar técnicas de eliminación de marcos JavaScript, pero puede que no sean efectivas en todos los exploradores.
Evitar el uso de credenciales de contraseña de propietario de recurso
El flujo de propietario de recurso permite a un cliente solicitar un token de acceso mediante un ID de usuario final, una contraseña y las propias credenciales del cliente. Este tipo de subvención presenta un mayor riesgo porque:
- Se encarga de recopilar las credenciales de usuario en la aplicación cliente (mantenga el antipatrón UID/contraseña).
- No presenta una pantalla de consentimiento para solicitudes de ámbito.
Excepto por motivos de migración, evite el uso de este tipo de permiso.
Utilizar la cabecera Cache-Control="no-store"

Esta cabecera minimiza el riesgo de no proteger el contenido autenticado y de filtrar datos confidenciales en proxies HTTP.
Evitar solicitudes con información confidencial enviada mediante parámetros de URL

Los parámetros de URL (utilizados en solicitudes GET) se pueden registrar en cualquier componente entre aplicaciones como logs de aplicación, servidores proxy, firewalls y componentes de borde de red.

Los dominios de identidad implantan puntos finales REST de búsqueda alternativos mediante POST que abordan este riesgo. Consulte la página Parámetros de Consulta para obtener más información.