Google introdujo 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 requieren acciones de los desarrolladores de apps de terceros, a continuación, se incluyen algunas prácticas recomendadas que otros desarrolladores consideraron útiles.
Usa OAuth incremental
Puedes usar la autorización incremental para solicitar inicialmente solo los permisos necesarios para iniciar tu app y, luego, solicitar permisos adicionales a medida que se requieran. El contexto de la app identifica el motivo de la solicitud al usuario.
Al acceder, tu app solicita permisos básicos, como el permiso de acceso al perfil y otros permisos iniciales que necesita para funcionar. Más adelante, cuando el usuario quiera realizar una acción que requiera permisos adicionales, tu app los solicitará y el usuario autorizará solo los permisos nuevos desde una pantalla de consentimiento.
Cuando compiles 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 pide que dé su consentimiento a un usuario del 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 representen 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 las APIs de Google, asegúrate de que cada una 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 los IDs de cliente de OAuth, usa proyectos de Google Cloud separados para las pruebas y la 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 usa Google Cloud Platform 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 solicitan 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 requiere 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 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 del dominio configure tu acceso varias veces.
Asegúrate de que los IDs de cliente de OAuth sean precisos
Consulta con 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 las pruebas y la producción para ayudar a los administradores a comprender 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 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 actualizan en la Consola del administrador. |
| Tipo | Sí | Es uno de los siguientes: 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 Android y iOS, ingresa el ID de cliente de OAuth o el ID del paquete o del paquete de aplicación 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 diagonal (“/”) para aplicar la configuración de acceso a la app a todo tu dominio. Para aplicar la configuración de acceso a unidades organizacionales específicas, agrega una fila a la hoja de cálculo para cada unidad organizacional y repite el nombre de la app, el tipo y el ID (por ejemplo, “/org_unit_1/sub_unit_1”). |
| Acceso | Sí | Es uno de los siguientes: de confianza, 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 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 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.