Documentación de Oracle Cloud Infrastructure

Gestión de la autorización mediante la API

La API de REST de los dominios de identidad soporta tanto la autorización basada en token como las firmas de solicitud de OCI. Por motivos de seguridad, no se puede acceder a la API de REST de los dominios de identidad utilizando solo el nombre de usuario y la contraseña que utiliza para conectarse al dominio de identidad. Para acceder a la API de REST de los dominios de identidad, necesita un token de acceso OAuth2 o una clave de API para utilizarla para la autorización.

La API de REST de los dominios de identidad utiliza el protocolo OAuth 2.0 para la autenticación y autorización, y soporta estos escenarios de autorización comunes:

  • servidor Web

  • Móvil

  • Aplicaciones JavaScript

En la sección Autorización se tratan los escenarios de OAuth 2.0 que soportan los dominios de identidad.

Esta sección contiene los siguientes temas:

Registro de una aplicación cliente

Una aplicación debe estar registrada como cliente OAuth 2 mediante el dominio de identidad. Los clientes OAuth son clientes HTTP que se pueden obtener y, a continuación, utilizar un token de acceso.

Complete los siguientes pasos para utilizar un cliente OAuth para acceder a la API de REST de los dominios de identidad:

  1. Conéctese al dominio de identidad con el nombre de usuario y la contraseña que se encuentran en el correo electrónico de bienvenida.

  2. Cree una aplicación cliente OAuth y anote el ID de cliente y el secreto de cliente.

    Nota

    Al configurar la aplicación cliente OAuth, seleccione los roles de aplicación que desea asignar a la aplicación. Esto permite a su aplicación acceder a las APIs de REST a las que puede acceder cada una de las funciones de aplicación asignadas. Cada rol de aplicación tiene ámbitos asignados que definen un nivel de acceso aún más detallado a las operaciones de API. Por ejemplo, seleccione Administrador de dominio de identidad en la lista. La aplicación podrá acceder a todas las operaciones de la API de los REST disponibles para la aplicación.

  3. Utilice el ID de cliente y el secreto de cliente para solicitar un token de acceso del servicio OAuth de IAM.

  4. Incluya el token de acceso en la cabecera HTTP adecuada al realizar llamadas a la API de REST.

Más información

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 segura de OAuth requiere:

  • Controles de seguridad implantados en todos los participantes de OAuth, que incluyen el servidor de autorización (IAM), el propietario del recurso (usuario), el cliente y las aplicaciones del servidor de recursos

  • Confidencialidad de la información clave: código, access_token, refresh_token, credenciales de cliente y credenciales de usuario

  • Autenticación del servidor establecida entre los participantes 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 ámbitos mínimos y tiempo de espera (para reducir la exposición en caso de divulgación y para admitir la revocación de tokens)

  • Uso de principios típicos de seguridad de la información como privilegio mínimo

Recursos

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

Nota

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

Lista de comprobación de recomendaciones de seguridad

En esta página se muestran las recomendaciones de seguridad más relevantes como 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 de servidor de recursos. Esto evita escuchas 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 ataques de reproducción.

  • Establecer 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 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 ataques de suplantación de identidad, proxy, comando man en el medio y suplantación de identidad para capturar códigos de autorización, tokens de acceso, credenciales de cliente y credenciales de usuario.

  • Considerar el 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

    El uso de HTTPS y la validación de CA de confianza impide la suplantación de identidad 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 privilegios mínimos

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

    La reducción del alcance, los flujos, los tipos de subvenciones y las operaciones mejora la estrategia de seguridad y reduce el impacto de una aplicación comprometida.

  • Proporcione un nombre significativo y una descripción a las aplicaciones

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

    El uso de nombres y descripciones de aplicaciones significativas puede evitar que los usuarios cometan errores durante la autorización del consentimiento y también contribuye a una mejor generación de 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, de una manera comprensible evita que el usuario cometa errores durante la autorización y contribuye a una mejor generación de informes de auditoría.

  • Evite los á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 denegarlo.

  • 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 los 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 implantar la revocación oportuna, puede configurar el token de acceso con una duración breve 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 implementaciones críticas de seguridad, implemente una rotación de secreto de cliente. Esto reduce el riesgo de que se explore un secreto de cliente comprometido.

Propietario de recurso (usuario)

  • Mantener informado al propietario del recurso

    El uso de ámbito con consentimiento proporciona transparencia al propietario del recurso y evita que las aplicaciones soliciten ámbitos que no son necesarios.

  • Conocimiento del usuario

    Enseñar a los usuarios cómo proteger sus credenciales e identificar el cliente, la aplicación del servidor de recursos y la legitimidad del 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 del usuario.

Desarrollo de aplicaciones

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

    Las aplicaciones deben conservar 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 (utilice 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

  • Proteger 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 centros y la denegación de servicio.

  • Lectura de tokens desde el 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 use 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, use el bloqueo del dispositivo para evitar el acceso no autorizado y revocar los tokens de actualización.

  • Validar la seguridad de la 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. Las amenazas relacionadas con el alojamiento y el desarrollo de aplicaciones no se abordan mediante dominios de identidad. Estas amenazas incluyen, entre otras, el acceso indirecto a las bases de datos y el almacenamiento de la aplicación, el secuestro selectivo, los scripts de sitios, la inyección de scripts/SQL y los flujos de confidencialidad de la información en la aplicación.

  • Aplicar menos privilegio durante solicitud de ámbito

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

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

    Un token con amplios ámbitos puede aumentar el impacto en la 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 del dominio de identidad en una solicitud directa de su 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 token para obtener más información sobre cómo validar el token.

    Nota

    Los servidores de recursos solo deben procesar la información una vez que se haya realizado toda la validación del 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.

  • Implantación de TLS de 2 Vías entre Aplicaciones de Cliente y Servidor de Recursos

    Para las aplicaciones esenciales de seguridad, puede implementar un TLS de 2 vías entre las aplicaciones de 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.

  • Evitar el secuestro de selección

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

    Para los navegadores más antiguos, se pueden utilizar técnicas de eliminación de marcos JavaScript, pero puede que no sean efectivas en todos los navegadores.

  • Evitar el uso de credenciales de contraseña de propietario de recurso

    El flujo de propietario de recursos permite a un cliente solicitar un token de acceso mediante el ID de usuario final, la 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 (mantiene el antipatrón UID/contraseña).

    • No presenta una pantalla de consentimiento para las solicitudes de ámbito.

    Excepto por motivos de migración, evite el uso de este tipo de subvención.

  • 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 aplicaciones, servidores proxy, firewalls y componentes de perímetro de red.

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