Google introdujo la configuración del control de acceso a apps para facilitar a los administradores de Google Workspace for Education el control del modo en que las apps de terceros acceden a los datos de Google de sus organizaciones cuando los usuarios acceden con sus cuentas de Google Workspace for Education. Si bien no se requieren acciones de los desarrolladores de apps de terceros, a continuación se incluyen algunas prácticas recomendadas que otros desarrolladores han encontrado útiles.
Usa OAuth incremental
Puedes usar la autorización incremental para solicitar inicialmente solo los alcances necesarios para iniciar tu app y, luego, solicitar alcances adicionales a medida que se requieran permisos nuevos. Luego, el contexto de la app identifica el motivo de la solicitud al usuario.
Cuando el usuario accede, tu app solicita permisos básicos, como el permiso de perfil de acceso y otros permisos iniciales que tu app requiere para funcionar. Más adelante, cuando el usuario quiera realizar una acción que requiera alcances adicionales, tu app solicitará esos alcances adicionales, y el usuario autorizará solo los alcances nuevos desde una pantalla de consentimiento.
Cuando crees un complemento de Google Classroom, debes seguir la orientación de Google Workspace Marketplace para proporcionar una lista completa de los permisos de OAuth que requiere tu app. Esto es necesario para que un administrador comprenda a qué permisos se le solicita a un usuario del dominio que dé su consentimiento.
Asegúrate de que todas las apps estén verificadas por OAuth
Todas las apps que acceden a las APIs de Google deben verificar que representan con precisión su identidad y su intención, tal como se especifica en la Política de datos del usuario de los servicios de la API de Google. Si mantienes varias apps que usan APIs de Google, asegúrate de que cada una de ellas se haya verificado. Los administradores pueden ver todos los IDs de cliente de OAuth asociados con tu marca verificada. Para ayudar a los administradores a evitar la configuración incorrecta de IDs de cliente de OAuth, usa proyectos de Google Cloud separados para pruebas y producción, y borra todos los IDs de cliente de OAuth que no se estén usando.
La verificación de la API de OAuth es un proceso que Google Cloud Platform usa para garantizar que las apps que solicitan permisos sensibles o restringidos sean seguras y cumplan con los requisitos. El proceso de verificación ayuda a proteger a los usuarios y los datos de Google Cloud del acceso no autorizado.
Las apps que solicitan permisos sensibles o restringidos deben cumplir con la Política de Datos del Usuario de los Servicios de las APIs de Google. Esta política exige que las apps protejan los datos del usuario y que solo los usen para los fines que el usuario haya autorizado. Es posible que las apps también deban someterse a una evaluación de seguridad independiente para verificar que cumplen con los requisitos de seguridad de Google Cloud.
Ten en cuenta que el proceso de verificación de la API de OAuth puede tardar varias semanas en completarse. Una vez que se verifique tu app, podrás solicitar los permisos sensibles o restringidos que necesites.
Consulta las preguntas frecuentes sobre la verificación de la API de OAuth para obtener más información.
Cómo controlar varios IDs de cliente de OAuth
Un proyecto de Google Cloud puede tener varios IDs de cliente de OAuth, lo que podría requerir que un administrador de dominio configure tu acceso varias veces.
Asegúrate de que los IDs de cliente de OAuth sean precisos
Consulta a tu equipo de desarrollo para comprender qué IDs de cliente de OAuth se usan para la integración con Google OAuth. Usa dos proyectos de Google Cloud diferentes para pruebas y producción, de modo que los administradores comprendan qué IDs de cliente de OAuth deben configurar. Borra los IDs de cliente obsoletos o desactualizados de tus proyectos de producción.
Carga de archivo CSV
Si tienes varios IDs de cliente, te recomendamos que aproveches la opción de carga masiva de CSV para ayudar a los administradores a configurar rápidamente todas tus aplicaciones.
Los campos son los siguientes:
| Campo | Obligatorio | Notas |
|---|---|---|
| Nombre de la aplicación | No | Ingresa el nombre de la app. Los cambios que realices en el nombre de la app en el archivo CSV no se actualizarán en la Consola del administrador. |
| Tipo | Sí | Puede ser una aplicación web, Android o iOS. |
| ID | Sí | En el caso de las apps web, ingresa el ID de cliente de OAuth que se emitió para la aplicación. En el caso de las apps para iOS y Android, ingresa el ID de cliente de OAuth o el ID del paquete o del bundle que usa la app en Google Play o en la App Store de Apple. |
| Unidad org. | Sí | El cliente debe completar este campo. Ingresa una barra inclinada (/) para aplicar el parámetro de configuración de acceso a la app a todo tu dominio. Para aplicar la configuración de acceso a unidades organizativas específicas, agrega una fila a la hoja de cálculo para cada unidad organizativa y repite el nombre, el tipo y el ID de la app. (por ejemplo, "/org_unit_1/sub_unit_1"). |
| Acceso | Sí | Uno de los siguientes: trusted, blocked o limited. |
Errores de OAuth
Se introdujeron dos mensajes de error con estos nuevos controles de administrador.
- Error 400: access_not_configured: Se recibe cuando se rechaza una conexión de OAuth porque tu app no se configuró.
- Error 400: admin_policy_enforced: Se recibe cuando se rechaza una conexión de OAuth porque el administrador bloqueó tu aplicación.
Usuarios designados como menores de 18 años
Los administradores pueden administrar el acceso a apps de terceros no configuradas para usuarios designados como menores de 18 años. Si un usuario ve el error “Acceso bloqueado: El administrador de tu institución debe revisar [nombre de la app]”, debe solicitar acceso desde el mensaje de error. Esto permite que el administrador revise la aplicación de terceros. Los administradores pueden decidir si permiten o bloquean las aplicaciones de terceros.