Google presentó la configuración de 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 requiere que los desarrolladores de apps de terceros realicen ninguna acción, a continuación, se incluyen algunas prácticas recomendadas que otros desarrolladores encontraron útiles.
Usa OAuth incremental
Puedes usar la autorización incremental para solicitar inicialmente solo los ámbitos necesarios para iniciar tu app y, luego, solicitar ámbitos adicionales a medida que se requieran nuevos permisos. Luego, el contexto de la app identifica el motivo de la solicitud al usuario.
Cuando accedes, tu app solicita permisos básicos, como el perfil de alcance de acceso y otros permisos iniciales que la app requiere para su funcionamiento. Luego, cuando el usuario quiera realizar una acción que requiera permisos adicionales, tu app solicitará esos permisos adicionales, y el usuario solo autorizará los permisos nuevos de una pantalla de consentimiento.
Cuando crees un complemento de Google Classroom, debes seguir las instrucciones 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 consentimiento a un usuario de dominio.
Asegúrate de que todas las apps estén verificadas con OAuth
Todas las apps que acceden a las APIs de Google deben verificar que representan con precisión su identidad y su intención, como se especifica en la Política de datos del usuario de los servicios de la API de Google. Si administras varias apps que usan las APIs de Google, asegúrate de que cada una esté verificada. Es posible que los administradores vean todos los IDs de cliente de OAuth asociados con tu marca verificada. Para ayudar a los administradores a evitar configurar IDs de cliente de OAuth incorrectos, usa proyectos de Google Cloud diferentes para pruebas y producción y borra todos los IDs de cliente de OAuth que no se usen.
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 las políticas. El proceso de verificación ayuda a proteger a los usuarios y los datos de Google Cloud del acceso no autorizado.
Las apps que soliciten permisos sensibles o restringidos deben cumplir con la Política de Datos del Usuario de los Servicios de la API 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 autorizó. Es posible que las apps también deban someterse a una evaluación de seguridad independiente para verificar que cumplan con los requisitos de seguridad de Google Cloud.
Ten en cuenta que el proceso de verificación de la API de OAuth puede tardar hasta 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 detalles.
Administra 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.
Cómo garantizar la precisión de los IDs de cliente de OAuth
Consulta con tu equipo de desarrollo qué IDs de cliente de OAuth se usan para integrar a OAuth de Google. Usa dos proyectos de Google Cloud diferentes para pruebas y producción para ayudar a los administradores a comprender qué IDs de cliente de OAuth 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 apps.
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í | Una de las siguientes opciones: 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ó a la aplicación. En el caso de las apps para iOS y Android, ingresa el ID de cliente de OAuth o el ID de paquete o paquete que usa la app en Google Play o en la App Store de Apple. |
| Unidad org. | Sí | Es información que debe completar el cliente. Ingresa una barra inclinada ('/') para aplicar la configuración de acceso de 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í | Es uno de los siguientes: confiable, bloqueado o limitado. |
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 no se configuró tu app.
- 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 encuentra el error “Acceso bloqueado: El administrador de tu institución necesita revisar [nombre de la app]”, debe solicitar acceso desde ese mensaje. Esto permite que el administrador revise la aplicación de terceros. Los administradores pueden decidir si permiten o bloquean las aplicaciones de terceros.