Recomendaciones de seguridad

Recursos

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

• El marco de autorización OAuth 2.0

• OAuth 2.0 Modelo de amenaza y consideraciones de seguridad

• Token web de JSON (JWT)

• Perfil de token web JSON (JWT) para permisos de autenticación y autorización de cliente OAuth 2.0

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 los Perfil de JWT para OAuth 2.0 Otorgamientos de autenticación y autorización de cliente 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.