Google introdujo la configuración de control de acceso a las apps para facilitar que los administradores de Google Workspace for Education controlen cómo 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 ninguna acción por parte 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 permisos adicionales si se requieren permisos nuevos. Luego, el contexto de la app identifica el motivo de la solicitud al usuario.
Durante el acceso, tu app solicita permisos básicos, como el perfil de alcance de acceso y otros permisos iniciales, que tu app requiere para el funcionamiento. Luego, cuando el usuario quiera realizar una acción que requiera permisos adicionales, tu app los solicitará, y el usuario solo autorizará los nuevos desde una pantalla de consentimiento.
Cuando compiles un complemento de Google Classroom, debes seguir la guía 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 los permisos con los que se solicita el consentimiento del usuario del dominio.
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 representen con exactitud su identidad y su intent según se especifica en la Política de Datos del Usuario de los Servicios de la API de Google. Si tienes 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 la marca verificada. A fin de ayudar a los administradores a evitar la configuración de IDs de cliente de OAuth incorrectos, usa proyectos de Google Cloud independientes para la prueba 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 normas. El proceso de verificación ayuda a proteger a los usuarios y 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 los usen solo 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 información.
Controla varios IDs de cliente de OAuth
Un proyecto de Google Cloud puede tener varios IDs de cliente de OAuth, lo que puede requerir que un administrador de dominio configure tu acceso varias veces.
Garantiza la precisión de los IDs de cliente de OAuth
Consulta con tu equipo de desarrollo a fin de comprender qué IDs de cliente de OAuth se usan para integrar a OAuth de Google. Usa dos proyectos diferentes de Google Cloud para pruebas y producción a fin de ayudar a los administradores a comprender qué ID de cliente de OAuth deben configurar. Borra los ID de cliente obsoletos o desactualizados de tus proyectos de producción.
Carga de archivo CSV
Si tienes varios IDs de cliente, te recomendamos aprovechar 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 | Obligatorias | Notas |
|---|---|---|
| Nombre de la app | 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 aplicación web, Android o iOS. |
| ID | Sí | En el caso de las apps web, ingresa el ID de cliente de OAuth emitido 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 App Store de Apple. |
| Unidad org. | Sí | Para que lo complete el cliente. Ingresa una barra diagonal (“/”) para aplicar la configuración de acceso a la app a todo el dominio. Para aplicar la configuración de acceso a unidades organizativas específicas, agrega una fila a la hoja de cálculo de cada unidad organizativa y repite el nombre, el tipo y el ID de la app. (por ejemplo, "/unidad_org.1/unidad_sub_1"). |
| Acceso | Sí | Puede ser trusted, block o limited. |
Errores de OAuth
Se incluyeron dos mensajes de error con estos nuevos controles para administradores.
- Error 400: access_not_configured: Se recibió 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 el nombre de la app”, debe solicitar acceso desde el mensaje de error. Esto permite que su administrador revise la aplicación de terceros. Los administradores pueden decidir si permiten o bloquean las aplicaciones de terceros.