Recorta los ámbitos OAuth para reducir la fricción en la revisión de la app

Por qué las revisiones de apps se atascan por los ámbitos OAuth

Las revisiones de OAuth se ralentizan por una razón simple: los permisos que solicitas no parecen necesarios según lo que el revisor puede ver y probar.

Los revisores suelen empezar por tu lista de ámbitos y preguntan: "Si apruebo esto, ¿qué puede leer o cambiar la app, y dónde se usa eso en el producto?" Si no pueden mapear rápidamente los ámbitos a pantallas y acciones, detienen la revisión y piden pruebas.

Una lista larga de ámbitos es una señal de alarma porque aumenta el riesgo para el usuario y puede parecer que la app recopila datos "por si acaso". Los ámbitos no usados son aún peor. Aunque nunca llames la API, el revisor solo ve el acceso potencial.

Las notas típicas de rechazo suenan así: "No queda claro por qué se necesita este permiso", "Los ámbitos solicitados son demasiado amplios para la funcionalidad descrita" o "No se pueden mapear los ámbitos a características". Una causa común es código inicial generado por plantillas o IA que solicita permisos extra (por ejemplo, un flujo básico de "Iniciar sesión con Google" que también pide modificar archivos o leer contactos).

La forma más rápida de salir del atasco es recortar los ámbitos al mínimo y explicar cada permiso restante en lenguaje llano que un revisor pueda verificar.

Ámbitos en lenguaje claro (y por qué importa el menor privilegio)

Un ámbito OAuth es un permiso que tu app solicita cuando un usuario conecta su cuenta. Cada ámbito indica al proveedor qué puede hacer tu app, como leer un perfil o acceder a eventos del calendario.

El principio de menor privilegio es la regla que los revisores quieren ver: solicita el conjunto mínimo de permisos necesarios para la función que el usuario espera. Si solo necesitas mostrar eventos del calendario, pedir acceso de lectura/escritura a todo el calendario es difícil de justificar.

Los ámbitos amplios generan preocupaciones de seguridad y privacidad porque aumentan lo que podría exponerse si algo sale mal (un bug, un token filtrado o un atacante). También perjudican la conversión: los usuarios deciden en segundos en la pantalla de consentimiento, y "demasiado acceso" se abandona.

Paso 1: Haz inventario de cada ámbito que solicita tu app

Antes de recortar nada, obtén una lista completa de lo que tu app solicita hoy. Muchos equipos omiten ámbitos que aún se piden en algún lugar, aunque la UI y la documentación digan lo contrario.

Los ámbitos suelen aparecer en tres lugares:

• Tu código (solicitud OAuth, llamadas al SDK)
• Tu entorno/configuración (vars de entorno, JSON/config móvil)
• La consola del proveedor (permisos activados durante pruebas)

Crea una tabla de inventario simple para que tu vista interna coincida con lo que los revisores verán.

Mientras llenas esto, vigila sorpresas comunes: el mismo ámbito pedido dos veces (en el código y por librerías por defecto), ámbitos heredados de experimentos antiguos y ámbitos que existen solo en la consola pero no en el código.

Haz una comprobación rápida: inicia sesión como usuario de prueba y anota el texto de la pantalla de consentimiento. Si ves permisos que no reconoces, deben ir en la tabla.

Paso 2: Mapea cada ámbito a una función visible para el usuario

Para los revisores, un ámbito no es "algo que la app necesita". Cada ámbito debe mapearse a una función que el usuario pueda ver y usar.

Para cada ámbito, responde dos preguntas en lenguaje claro:

1. ¿Qué función deja de funcionar si se quita este ámbito?
2. ¿Qué acción del usuario dispara esa función?

Esto convierte "leer calendario" en un flujo concreto y comprobable como: "El usuario hace clic en Importar eventos, selecciona un rango de fechas y mostramos las próximas reuniones en el panel."

Para la documentación, mantenlo simple:

• Nombre de la función (las palabras usadas en tu UI)
• Disparador (el clic o paso)
• Datos usados (lectura/escritura)
• Esencial vs opcional
• Cuándo solicitarlo (registro vs solo cuando se necesita)

Sé estricto sobre esencial vs opcional. Si un ámbito solo soporta una función adicional, no lo pidas en el primer inicio de sesión. Pídelo solo cuando el usuario intente usar esa función. A los revisores les gusta esto porque el aviso de consentimiento coincide con la intención del usuario.

Ejemplo: si tu app tiene Inicio de sesión más una función opcional de Sincronizar contactos, el inicio de sesión debe usar ámbitos básicos de identidad. Los ámbitos de contactos deben aparecer solo cuando el usuario haga clic en Sincronizar contactos por primera vez, con una explicación de una sola oración.

Paso 3: Reemplaza ámbitos amplios por alternativas más concretas

Los ámbitos amplios son una de las formas más rápidas de ralentizar una revisión de OAuth. Si quieres mantener funciones pero reducir riesgos, reemplaza permisos "todo" por el ámbito más estrecho que aún soporte lo que el usuario realmente hace.

Comienza con lo básico:

• Prefiere solo lectura sobre lectura/escritura cuando puedas.
• Prefiere un ámbito específico del producto en vez de uno de toda la suite.
• Para archivos, prefiere la carpeta de la app o archivos seleccionados por el usuario sobre acceso total al drive.

La autorización incremental ayuda también. Pide lo mínimo en el primer inicio (a menudo solo identidad) y luego solicita ámbitos adicionales solo cuando el usuario desencadene la función que los requiere.

Si tu app solo necesita iniciar sesión y mostrar el nombre, solicitar almacenamiento, correo o calendario es difícil de defender. Mantén solo identidad y pide los ámbitos de datos en el momento en que el usuario habilite la función.

Paso 4: Elimina ámbitos no usados de forma segura

Una vez que estés seguro de que un ámbito no es necesario, elimínalo de forma controlada. Aquí es donde los equipos se ponen nerviosos, porque el riesgo es romper un flujo poco usado. Hecho con cuidado, la recompensa es grande: menos permisos y menos preguntas de los revisores.

Primero, demuestra que realmente no se usa. No te fíes de la memoria. Busca en el código puntos finales que requieran el ámbito y revisa la configuración donde se ensamblan los ámbitos.

También revisa usos ocultos que pueden no aparecer en la UI principal: workers en background, tareas programadas, páginas solo de admin y manejadores de webhooks.

Flujo seguro para eliminar

Usa una secuencia repetible para que puedas revertir rápidamente:

• Identifica los endpoints/acciones vinculados al ámbito y confirma que no se llaman.
• Revisa rutas no obvias (cron jobs, colas, webhooks, herramientas internas).
• Elimina el ámbito de tu solicitud de auth y de la configuración de consentimiento.
• Despliega a staging y ejecuta los flujos reales de usuario.
• Monitorea errores durante varias horas (o un día) antes de quitar el siguiente ámbito.

Las funciones muertas son una razón común por la que los ámbitos permanecen. Si alguna vez tuviste "importar contactos" o "sincronizar calendario" y ahora está deshabilitado, el permiso puede seguir siendo solicitado aunque nada lo use.

Mantén un pequeño registro de eliminación

Los revisores a menudo preguntan por qué cambió un permiso. Mantén un registro breve: qué ámbito eliminaste, qué soportaba antes (si algo), cómo confirmaste que no se usaba y la fecha.

Haz que tus explicaciones de permisos sean fáciles de verificar para los revisores

Los revisores no intentan adivinar tu intención. Quieren confirmar que cada permiso coincide con una función real y que los usuarios reciben la misma explicación en todas partes: pantalla de consentimiento, UI dentro de la app y texto de la política.

Actualiza el texto de la pantalla de consentimiento para que describa lo que la app hace hoy, no lo que planeaste hace meses. Si eliminaste una función, quita también el texto relacionado. El texto desajustado es una forma fácil de provocar preguntas de seguimiento.

Escribe “un permiso, un propósito”

Para cada ámbito restante, escribe una oración que responda:

• ¿Qué datos?
• ¿Por qué lo necesitas?
• ¿Cuándo accedes a ellos?

Ejemplo: "Leer tus eventos de Google Calendar para mostrar tus próximas reuniones en el panel cuando conectes tu cuenta."

Evita frases vagas como "para mejorar tu experiencia" o "para automatizar". No dicen al revisor qué tocas, cuándo o por qué.

Facilita la verificación manteniendo nombres coherentes:

• Usa los mismos nombres de función en la UI y en el texto de consentimiento.
• Dispara las solicitudes en el momento en que se usa la función (no en el primer inicio).
• Añade una nota breve en la app cerca del botón de conectar que repita la razón.
• Si el acceso es opcional, dilo y muestra que la app sigue funcionando sin él.

Prueba después de recortar: demuestra que nada se rompe

Tras recortar ámbitos, la app puede seguir funcionando en tu cuenta habitual porque previamente concediste acceso más amplio. Prueba como un usuario nuevo y como un revisor.

Usa una cuenta de prueba completamente nueva (o un workspace limpio) que nunca haya autorizado tu app. Ejecuta todo el flujo de inicio de sesión y configuración desde cero.

Luego prueba los casos límite que interesan a los revisores:

• Revoca el acceso de la app y vuelve a intentarlo (debe autenticarse de nuevo limpiamente).
• Expira tokens o invalida refresh tokens (debe recuperarse sin bucles).
• Concede solo los ámbitos mínimos (sin fallos, sin pantallas en blanco).
• Niega un ámbito opcional (la función se desactiva con un mensaje claro).
• Usa un segundo dispositivo o sesión de navegador (para detectar problemas de redirect/state).

Si un ámbito es realmente opcional, la función debe degradarse con gracia. Por ejemplo: mostrar "Conecta tu calendario para activar recordatorios" en lugar de fallar cuando se carga la pantalla del calendario.

Tras cualquier cambio de ámbito, repite los pasos de verificación del proveedor usando las mismas instrucciones que planeas enviar: configuración clara, clics exactos y qué debe ver el revisor en cada paso.

Errores comunes que provocan rechazos o largas idas y venidas

La mayoría de las demoras no son por tu producto. Ocurren porque el revisor no puede emparejar cada permiso con una función real, en pantallas reales, con el menor acceso necesario.

Dos patrones causan la mayor parte de problemas:

• Acceso de escritura cuando la función solo necesita lectura (por ejemplo, pedir permiso de edición cuando solo muestras datos).
• Solicitarlo todo en el primer inicio de sesión, incluso para funciones opcionales.

Las explicaciones vagas también ralentizan las revisiones. "Mejorar la experiencia" o "por funcionalidad" no dicen al revisor qué datos tocas, cuándo o por qué.

Otras discordancias comunes incluyen ámbitos antiguos dejados por prototipos, texto de consentimiento que no coincide con el comportamiento, instrucciones para el revisor que hacen referencia a funciones no presentes en la build y un ámbito comodín usado cuando uno más estrecho serviría.

Lista rápida antes de reenviar para revisión

Antes de reenviar, asegúrate de que cada permiso cuente una historia simple y verificable.

• Para cada ámbito, escribe el nombre exacto de la función que potencia y un paso que el revisor pueda seguir para verla en la UI.
• Confirma que estás usando el ámbito más estrecho que soporte la función.
• Asegúrate de que el texto de la pantalla de consentimiento coincida con el comportamiento real ("leer" vs "gestionar").
• Elimina ámbitos heredados de prototipos y boilerplate.
• Vuelve a probar de extremo a extremo con una cuenta limpia (sin tokens en caché).

Un hábito práctico: guarda una nota de justificación de permisos de una oración por ámbito en docs internas. Cuando un revisor pregunte "¿por qué necesitas esto?" puedes responder rápido y señalar una pantalla específica.

Ejemplo: recortar ámbitos para destrabar una revisión estancada

Un fundador tenía un prototipo construido por IA que se conectaba a Google Drive. La app pedía acceso completo a Drive porque el código de plantilla usaba el ámbito más amplio por defecto. En realidad, la única función de Drive era exportar un informe en PDF y guardarlo en Drive del usuario.

La solución fue recortar los ámbitos para coincidir con esa única acción. Reemplazamos el permiso de acceso total a Drive por un permiso más estrecho de crear archivos y dejamos de pedirlo durante el inicio de sesión. En su lugar, el permiso de Drive se solicitaba solo cuando el usuario hacía clic en Exportar.

Qué cambió en la app

Tres cambios facilitaron que un revisor confirmara el comportamiento:

• Se quitó el permiso de Drive de la pantalla de consentimiento inicial.
• Un botón Exportar a Drive disparaba un prompt de consentimiento separado.
• Las llamadas a la API de Drive se limitaron a crear el PDF, sin listar, leer, borrar o modificar archivos existentes.

La nota al revisor que funcionó

La resubmisión incluyó una nota breve como:

"El permiso de Drive se solicita solo cuando un usuario hace clic en Exportar a Drive. Se usa para crear un archivo PDF nuevo en el Drive del usuario. La app no lee, lista, modifica ni borra archivos existentes. Para verificar: inicia sesión sin acceso a Drive, abre Informes, haz clic en Exportar a Drive, completa el consentimiento y confirma que se crea un único PDF nuevo."

El feedback mejoró de inmediato: menos preguntas de seguimiento y la aprobación pasó de "estancada por más de una semana" a "aprobada en unos 2 días".

Siguientes pasos si tu app fue generada por IA o la lista de ámbitos está desordenada

Los códigos generados por IA a menudo piden más permisos de los que necesitan. Las herramientas pueden copiar ámbitos de ejemplos, añadir valores por defecto de SDK o dejar características medio construidas que aún solicitan acceso.

Si no puedes señalar el archivo/función exacta que usa cada ámbito, o los revisores ya hicieron preguntas que no puedes responder con seguridad, una auditoría enfocada suele ser más rápida que adivinar.

Si trabajas con un prototipo generado por IA de herramientas como Lovable, Bolt, v0, Cursor o Replit, FixMyMess (fixmymess.ai) ayuda a los equipos a diagnosticar el uso de ámbitos, eliminar permisos arriesgados o no usados y verificar que la app sigue funcionando end-to-end antes de reenviar.