Google OAuth: inicio y política de privacidad

Qué comprueban los revisores

1. Una página pública reconocible

   Google comprueba que el inicio identifica la aplicación, explica su función y enlaza la política de la pantalla de consentimiento.

   Fuente oficial: Google: Homepage requirements

2. Declaraciones de datos precisas

   Explica cómo accede, usa, almacena y comparte datos de Google. El comportamiento real debe coincidir.

   Fuente oficial: Google: Privacy disclosures

3. Permisos sensibles justificados

   En la revisión de permisos sensibles, justifica cada permiso y demuestra su función y flujo de autorización.

   Fuente oficial: Google: Sensitive-scope submission

Riesgos de rechazo documentados

1. Falta de propiedad del dominio

   Los dominios autorizados sin verificar incumplen un requisito. Comprueba la propiedad antes del envío.

   Fuente oficial: Google: Domain ownership

2. Permisos que exceden la función

   Una justificación insuficiente puede causar rechazo; Google puede exigir permisos menores. No se afirma ninguna frecuencia.

   Fuente oficial: Google: Narrowest scopes

3. Uso de datos no declarado

   Los usos secundarios ocultos pueden incumplir la política y poner en riesgo el acceso a la API. Una política genérica no corrige diferencias.

   Fuente oficial: Google: Prohibited deceptive use

Lista para presentar la solicitud

1. Comprueba el público y las excepciones

   Identifica el público previsto y el estado de publicación del proyecto antes de reunir pruebas. Compara el uso real con las excepciones de Google, incluidas pruebas e implementación interna cuando corresponda. Registra por qué se aplica una excepción. No equipares pocos clientes con una configuración Interna de una organización ni supongas que las pruebas eliminan toda limitación.

   Fuente oficial: Google: Verification exceptions

2. Pon el texto completo de la política en tu dominio

   Publica tu política de privacidad en una dirección HTTPS pública en el dominio de la página de inicio de tu app, por ejemplo https://harbor.example/privacy.html. Pon el texto completo en el cuerpo de la página: Google no puede procesar una política que solo aparece dentro de un iframe u otro documento insertado. El texto debe leerse sin iniciar sesión. Cuando tu app empiece a usar una herramienta nueva o datos nuevos, actualiza esta página.

   Fuente oficial: Google: Formato y alojamiento de la política

3. Publica páginas coherentes

   Prepara una página de inicio pública que explique la aplicación y una política legible en el mismo dominio. Enlaza esa política desde el inicio e introduce la dirección coincidente en la configuración de consentimiento. Contrasta el tratamiento de datos de Google descrito con la implementación antes de solicitar la revisión.

   Fuente oficial: Google: Privacy-policy links

4. Verifica los dominios autorizados

   Enumera los dominios registrables de las URL de consentimiento y credenciales OAuth, incluidos los destinos de redirección y orígenes JavaScript pertinentes. Configura los dominios autorizados y verifica la propiedad en Search Console con una cuenta asociada al proyecto. Para un subdominio, comprueba el dominio registrable superior, no cada ruta de URL.

   Fuente oficial: Google: Authorized domains

5. Verifica y publica la marca

   En el proyecto seleccionado de Cloud, abre Marca y completa identidad, contacto y enlaces. Ejecuta Verificar marca, revisa los problemas indicados y corrígelos. Cuando el resultado permita publicar, usa Publicar marca. Consulta después el Centro de verificación para los requisitos de acceso; una marca en borrador aprobada todavía no está publicada.

   Fuente oficial: Google: Brand submission

6. Prepara la demostración de permisos

   Para cada permiso sensible que exija revisión, explica la función implementada y por qué no bastaría un acceso menor. Graba un vídeo oculto con la autorización OAuth en inglés y las funciones habilitadas por cada permiso. Incluye el nombre y el ID de cliente exigidos. La fuente no exige que toda interfaz funcional esté en inglés.

   Fuente oficial: Google: Sensitive-scope submission

7. Tramita aparte la revisión de acceso

   Con la marca publicada, consulta en el Centro de verificación el estado de acceso aplicable. Declara los permisos realmente solicitados, aporta justificaciones y demostración, y revisa los buzones de soporte y contacto del proyecto. Responde a las aclaraciones; publicar el inicio o la política no completa la revisión de permisos sensibles o restringidos.

   Fuente oficial: Google: Sensitive-scope submission

Ejemplo

1. Aplicación ficticia: Agenda Harbor

   Entrada ficticia: Agenda Harbor solo muestra entradas del calendario que el usuario elige durante una sesión activa. Suponemos que conserva los detalles en memoria, sin guardarlos en su base de datos ni enviarlos a analítica. El titular enumera las operaciones API implementadas, compara permisos y registra el menor que las permite. Aquí no se prescribe un permiso concreto. Resultado esperado: una ficha función-operación-permiso que justifica por qué sobra un acceso mayor. Los supuestos de memoria y ausencia de comunicación deben verificarse en el código antes de publicarlos.

   Fuente oficial: Google: Minimum permissions

2. Ficha de dominio ficticio

   Entrada ficticia: el titular controla harbor.example y prepara https://harbor.example/ como inicio y https://harbor.example/privacy.html como política. El inicio explica la visualización del calendario y enlaza esa URL exacta. El titular introduce la misma dirección en el consentimiento y comprueba ambas páginas sin sesión. Resultado esperado: una ficha de envío con URL coincidentes y una comprobación independiente de propiedad. Una política alojada en otro servicio no acredita la propiedad de harbor.example ni sustituye la publicación exigida en el mismo dominio.

   Fuente oficial: Google: Privacy policy requirements

3. Escribe solo prácticas confirmadas

   Entrada ficticia: el titular ha confirmado que los detalles de eventos duran solo durante la sesión, pero no ha revisado los registros de errores ni el almacenamiento de tokens OAuth. El borrador describe la finalidad confirmada y marca ambas incógnitas para ingeniería. El equipo comprueba si esos sistemas conservan datos de Google y actualiza inventario y política antes del envío. Resultado esperado: una lista de pruebas por declaración, no una afirmación incondicional de que nada se almacena. Si el comportamiento real difiere, las declaraciones y la demostración deben reflejarlo.

   Fuente oficial: Google: Identity and intent

https://harbor.example/
https://harbor.example/privacy.html

Preguntas frecuentes

1. ¿Basta una URL de privacidad?

   No. La revisión sensible aplicable también necesita justificación y una demostración del acceso solicitado.

   Fuente oficial: Google: Sensitive-scope submission

2. ¿Puedo enviar una política alojada en otro servicio o en un iframe?

   No como atajo. Google lee el texto de la política en el cuerpo de la página y no puede procesar una política que solo aparece en un iframe. Una URL en otro servicio no acredita la propiedad de tu dominio. Google documenta algunas alternativas para dominios verificados del titular o de la organización matriz, pero ninguna convierte un servicio de alojamiento ajeno en tu dominio.

   Fuente oficial: Google: Publicación de la política de privacidad

3. ¿Están exentas las aplicaciones internas?

   Solo las aplicaciones de una organización con configuración interna cumplen esa excepción. Un público pequeño no equivale a esa configuración.

   Fuente oficial: Google: Internal-only FAQ