software1

Aprenda a preparar su aplicación para la revisión de OAuth



Publicado por Nafis Zebarjadi, Gerente de Producto, y Adam Dawes, Gerente Senior de Producto

El Proyecto Strobe fue lanzado para dar a los usuarios control sobre sus datos y darles a los desarrolladores reglas de tráfico más precisas para que todos puedan confiar en los suyos. Los datos están a salvo. Como resultado de estos esfuerzos, hemos ampliado nuestro programa de revisión de aplicaciones para incluir más aplicaciones y más tipos de acceso a datos. Es importante comprender cómo funciona el proceso para ayudarlo a aprovechar al máximo su aplicación y agilizar el proceso de revisión. Aquí lo guiamos a través del proceso de preparación de su aplicación para la revisión de OAuth.

Preparación para la revisión

Primero, debe confirmar si su aplicación necesita ser revisada. La revisión de la aplicación solo es necesaria si desea iniciar completamente su aplicación para usuarios finales o usuarios empresariales, y la aplicación solicita áreas sensibles o restringidas. No es necesario revisar las aplicaciones que no son sensibles, están en desarrollo o que se acaban de crear para sus propios usuarios de G Suite. Si la aplicación es solo para usuarios de su propia organización, seleccione el tipo de aplicación Interna para restringir el uso de la aplicación en su propia organización y omita la revisión.

Una vez que comienza la revisión de la aplicación, no es fácil realizar actualizaciones a la configuración de la API de Google de su aplicación. Si realiza cambios durante el procedimiento, deberá comenzar de nuevo. Por lo tanto, es importante implementar su aplicación antes de comenzar la revisión para evitar demoras.

Determinar si su aplicación está utilizando áreas confidenciales o restringidas

Primero, debe verificar su código en cada plataforma para determinar qué secciones de OAuth (API de Google) necesita su servicio. Asegúrese de que esto se haga en cada cliente. A menudo encontramos que las aplicaciones solicitan diferentes secciones en diferentes plataformas y luego inician la revisión de la aplicación en un subconjunto de las secciones que realmente usan sus clientes. A menudo puede encontrar las secciones buscando "www.googleapis.com/auth" en su código. No todas las áreas heredadas contienen esta cadena. Como resultado, es posible que también desee buscar el código de la Biblioteca API de Google que usa (en la plataforma) para determinar qué áreas se solicitan, o consulte nuestro directorio .

Después de identificar todas las áreas que usan sus aplicaciones, puede usar Cloud Console (API y servicios -> Credenciales -> Aprobación de OAuth) para ver si son privados o restringidos Pantalla -> Ámbitos para las API de Google) y haga clic en el botón "Agregar área". Esto abre la siguiente ventana:

  Google Cloud Console agrega estado a la herramienta de cliente OAuth

Si el alcance tiene un icono de candado, el alcance es sensible o ] restringido y que utiliza el Revise las aplicaciones antes de poder interactuar con los usuarios de Google en general.
Habilitar

[BeachtenSiedassdasToolnurBereichefürAPIsauflistetdieSiefürIhrProjektaktivierthabenWennkeinBereichaufgelistetistmüssenSiezuerstdieentsprechendeAPIfürIhrProjektinderAPIbiblioteca . El hecho de que no vea el área utilizada en su código puede significar que ha configurado clientes en diferentes proyectos.]

Configuración de la estructura correcta del proyecto

Las aplicaciones se revisan y aprueban a nivel de proyecto, por lo que debe asegurarse de haber configurado correctamente a sus clientes antes de comenzar la validación de la aplicación. Si tiene varios proyectos, cada uno debe pasar por el proceso de revisión de la aplicación de uno en uno.

Cuándo agregar múltiples clientes a un proyecto: Su aplicación puede tener múltiples clientes para admitir diferentes plataformas, como Android, Web e iOS. Idealmente, todos estos clientes deberían estar en el mismo proyecto, ya que esto equilibra la experiencia con el consentimiento entre clientes . Si los clientes están en el mismo proyecto, los usuarios solo necesitan aprobar uno de los clientes. Otros clientes pueden recuperar automáticamente tokens sin obligar al usuario a rehacer el flujo de consentimiento para las mismas áreas solicitadas. El usuario acepta compartir datos con su servicio, sin importar qué plataforma utilice, y sus términos de servicio deben ser los mismos en todas las plataformas.

Momento en que los clientes se dividen en proyectos separados: Su organización también puede tener múltiples aplicaciones que publique a los usuarios. Es posible que desee o no alojar los clientes para sus diversas aplicaciones en el mismo proyecto. Si las diferentes aplicaciones usan el mismo sistema de inicio de sesión, se aplican las mismas políticas de privacidad y los usuarios reconocen la marca del editor de todas las aplicaciones, entonces tiene sentido tener a todos los clientes en el mismo proyecto. Por ejemplo, si PersonalFinance Corp tiene aplicaciones de contabilidad, presupuesto e impuestos que utilizan el mismo inicio de sesión, política de privacidad y usuario de la marca PersonalFinance Corp, lo mejor es organizarlas todas en el mismo proyecto. Sin embargo, si el editor de CoolGames tiene muchos títulos con diferentes sistemas de inicio de sesión y políticas de privacidad o los usuarios están más familiarizados con cada título de juego que la marca CoolGames, debe usar proyectos separados.

Reorganizar proyectos: No es posible posponer o reorganizar a los clientes una vez que se han creado. Si desea realizar cambios, puede crear nuevos clientes en un proyecto centralizado o hacer que cada aplicación sea revisada individualmente. Si crea nuevos clientes en un proyecto centralizado, actualice sus aplicaciones para usar el nuevo cliente y descarte los clientes antiguos. El problema con este enfoque es que su aplicación puede necesitar obtener el consentimiento del usuario nuevamente (a menos que el usuario haya acordado con su otro cliente). Alternativamente, puede dejar a sus clientes en proyectos separados. Sin embargo, cada proyecto debe someterse a una revisión de la aplicación de forma independiente, y los usuarios deben acordar individualmente con cada uno de sus clientes.

Configuración de proyectos de prueba y producción: También es útil para muchos desarrolladores tener un proyecto de prueba paralelo en su proyecto de producción. Esto facilita cambiar los ámbitos u otras propiedades de la aplicación y probar el comportamiento sin tener que hacer la revisión de la aplicación.

Configuración de su proyecto

Si su aplicación necesita revisión, debe asegurarse de que la información sobre su proyecto esté actualizada para evitar demoras.

Propietario del proyecto

Al realizar cambios en nuestro ecosistema API, es importante asegurarse de que sus proyectos tengan información de contacto actualizada. A menudo tenemos que enviar notificaciones de cambios, y los desarrolladores se han perdido actualizaciones importantes porque la información de contacto incorrecta ha provocado que su aplicación se desactive inesperadamente. Una forma de asegurarse de que su equipo reciba notificaciones es crear un Grupo de Google que actúe como un alias para un grupo estable en su organización (y configure el grupo para que usted Recibir correos electrónicos de no miembros). Otra opción es crear un recurso de organización en la consola de la nube para que los recursos de sus clientes se puedan administrar y restaurar de forma centralizada cuando los propietarios abandonan la empresa. También es una buena idea asegurarse de que los propietarios de los clientes Android / iOS / Web también sean propietarios o editores del proyecto. La verificación de dominio también es necesaria para cada aplicación. Por lo tanto, agregue su administrador de DNS al proyecto para que la persona pueda completar fácilmente el proceso.

Utilice Cloud IAM en la consola de la nube (Cloud Console -> IAM y admin -> IAM) para actualizar los propietarios del proyecto.

Información de marca y revisión de dominio

La información de marca incluye el nombre y el logotipo de su aplicación. Es importante que sean correctos, ya que los usuarios usan esta información para decidir si conocen su aplicación y confían en ella. La verificación verifica que usted posee la marca y el logotipo y que coinciden con la información de su sitio. Si realiza cambios, su marca previamente aprobada continuará mostrándose hasta que se pueda verificar la nueva información.

  Pantalla de aprobación de OAuth con un dominio de redireccionamiento

También debe verificar el dominio asociado con su marca. Esto es cierto incluso si solo usa versiones de Android / iOS de su aplicación porque necesita un sitio web donde su política de privacidad pueda ser alojada públicamente. Usted comienza la validación del dominio al vincular su dominio a su proyecto en la consola de la nube (API y servicios -> Comprobador de dominio). Luego debe ir a Search Console para demostrar que posee el dominio y lo controla.

La validación de dominio es una característica de seguridad importante para sus clientes web. Si tiene clientes web en su proyecto, para cada uno de estos clientes, un dominio ya verificado debe coincidir con los URI de redireccionamiento autorizados u Orígenes de JavaScript autorizados. De esa manera, podemos garantizar que los tokens OAuth solo se devolverán a su aplicación.

  Agregar un dominio autorizado a un proyecto de Google Cloud en la pestaña

Áreas

Dado que ya ha identificado las áreas que usa su aplicación, ahora debe considerar si puede cambiar el alcance a ellas para minimizar su acceso a datos. Nuestra Política de datos de usuario API requiere que solo solicite la información que necesita su aplicación y que el usuario entienda cómo usarla. No es apropiado acceder a los datos de usuario de Google para fines alternativos, como publicidad e investigación de mercado.

En particular, desea intentar evitar el uso de áreas restringidas . El proceso de revisión de áreas restringidas puede llevar varias semanas más que las áreas sensibles. Además, se requiere una amplia documentación. Es posible que deba realizar una evaluación de seguridad de un tercero por la cual debe pagar. Actualmente, solo ciertas áreas de Gmail están restringidas, pero hemos anunciado [19459559] que la mayoría de las áreas de Drive también estarán restringidas a principios de 2020.

Si su aplicación necesita acceder a un área restringida, debe diseñar su aplicación para que los datos de usuario de Google siempre se almacenen solo en el lado del cliente del dispositivo del usuario (como una aplicación Contact Manager). El almacenamiento de datos en la nube o en sus propios servidores requiere una evaluación de seguridad de terceros (a su cargo) y también puede causar problemas importantes para resolver los problemas de seguridad encontrados durante la evaluación.

Una vez que haya decidido las áreas que necesita su aplicación, asegúrese de que estén registradas en su proyecto y se reflejen en el código de su aplicación. Hemos visto muchos casos en los que el código de un desarrollador llama a otras áreas distintas de las registradas en la consola en la nube. En este caso, sus usuarios verán un error de aplicación no verificado . Muchos desarrolladores solicitan ayuda para la solución de problemas porque sus usuarios ven inesperadamente estos errores a pesar de que su aplicación ha sido aprobada. Esto se debe inevitablemente a que el código no coincide con lo que se verificó. Si desea agregar nuevas secciones a su aplicación, debe aprobar estas secciones antes de comenzar la funcionalidad en su aplicación de producción (un cliente de prueba es esencial aquí).

Cuando piense en áreas, también debe considerar cómo y cuándo solicitar el consentimiento de sus usuarios. Se recomienda no solicitar sino utilizar el permiso incremental para permitir que un usuario acceda a una función en particular, si así lo desea. Esta es una excelente manera de generar confianza porque el usuario interactúa con una función en particular, ve el beneficio de la función y comprende por qué otorgar un permiso particular hace que la función sea más útil.

Política de privacidad

Nuestro objetivo al revisar las aplicaciones es garantizar que todos los datos que los usuarios seleccionen para su divulgación a terceros estén bien administrados y cumplan con las expectativas de los usuarios para su uso. Su política de privacidad es su misión pública para sus usuarios y, para nosotros, evidencia crucial de que se cumplen las expectativas de los usuarios.

Debe incluir un enlace a su política de privacidad en su sitio web. Si el dominio donde aloja esta política no se analiza, su aplicación no se analizará. Si su aplicación es puramente móvil y no incluye un componente del lado del servidor, aún necesitará una política de privacidad. Sin embargo, puede ser muy fácil describir que su aplicación almacena solo datos en el dispositivo de un usuario.

Google no puede proporcionar información sobre su política de privacidad. Sin embargo, si su aplicación solicita áreas restringidas, revisaremos sus políticas para comprender cómo piensa utilizar esos datos y para asegurarnos de que satisfagan nuestras necesidades. Asegúrese de comprender los Requisitos de uso limitado y póngase en contacto con su asesor legal para asegurarse de que su Política de privacidad cumpla con los requisitos . Para ayudar a aclarar cómo su aplicación maneja el contenido del correo electrónico, también recomendamos agregar lo siguiente a la página de inicio de su aplicación: "El uso que hace la aplicación de la información de la API de Gmail está sujeto a las limitaciones de Google ". Necesario si su política de privacidad no es específica para el uso de contenido de correo electrónico.

Envíe su aplicación para su revisión

Después de haber configurado sus proyectos con toda la información requerida, puede enviar su aplicación para su revisión. Dependiendo de las áreas que solicite, hay tres tipos diferentes de revisión de aplicaciones, cada una de las cuales dura una cantidad de tiempo diferente. Si comienza la revisión con un conjunto de intervalos y luego descubre que necesita otros paneles, generalmente necesita completar el escaneo existente antes de poder comenzar el proceso nuevamente. Esto puede generar frustración y prolongar todo el proceso de revisión.

Verificación de marca comercial (2-3 días)

La verificación de marca comercial es nuestro proceso más directo y confirma que su marca y logotipo son suyos. Este es un paso opcional si su aplicación solicita áreas no sensibles, como el inicio de sesión de Google, y generalmente solo demora de 2 a 3 días hábiles. Si su aplicación no se somete a una revisión de marca registrada, los usuarios solo verán su nombre de dominio en la página de consentimiento.

Revisión de áreas sensibles (3-5 días)

A partir de junio de 2019, ampliamos significativamente la clasificación de áreas sensibles y solicitamos una revisión más completa para las nuevas aplicaciones que acceden a estas áreas. Las aplicaciones existentes que ya están accediendo a áreas sensibles deben completar este proceso de revisión en la segunda mitad de 2019.

La revisión de la sección confidencial incluye la revisión de la marca y el dominio. Comprueba si la política de privacidad es claramente visible en la página de inicio de su aplicación. También revisamos su aplicación y política de privacidad para nuestros Servicios API: Política de datos del usuario (19459008) y buscamos prácticas fraudulentas. La política de privacidad debe especificar cómo su aplicación accede, usa, almacena o comparte la información del usuario de Google. Su uso de los datos de usuario de Google debe limitarse a los descritos en su política de privacidad publicada.

También se requiere un video de YouTube o Drive-Free Drive para comprender cómo los usuarios perciben sus solicitudes de alcance y mostrar cómo se benefician al otorgarle acceso. La identidad de su aplicación debe ser evidente en el video (incluida la identificación del cliente de la aplicación), y debe resaltar la propuesta de valor que le comunica al usuario antes de solicitar el espacio.

Hasta que se complete la revisión, los usuarios verán una página de aplicación no verificada si su aplicación solicita un área que necesita revisión. Hasta 100 usuarios pueden otorgar acceso mientras su aplicación no está verificada. Después de eso, a los usuarios se les negará el acceso a su aplicación hasta que se complete la revisión.

  Pantalla de aplicación móvil no verificada

La verificación de privacidad confidencial generalmente demora de 3 a 5 días hábiles si no hay problemas con su aplicación.

Verificaciones de alcance limitado (4-6 semanas)

La verificación de alcance limitado es un proceso mucho más complejo. Además de todos los pasos para una revisión sensible del alcance, su aplicación estará sujeta a un proceso de revisión de privacidad más estricto para garantizar que su uso de los datos de usuario de Google cumpla con nuestros Requisitos de uso limitado . Solo se consideran los tipos de aplicación permitidos para acceder a áreas restringidas. Si su aplicación almacena datos en un servidor, debe aprobar una calificación de seguridad anual .

Realizamos una comprobación de errores antes de hacer clic en el botón Enviar para revisión. Aquí hay algunas razones comunes por las que no se puede hacer clic en el botón:

  • Sin dominio confirmado
  • La URL de política de privacidad, los URI de redireccionamiento autorizados u orígenes para su cliente no coinciden con un dominio autorizado
  • No se han agregado nuevas secciones al proyecto que requieran revisión

Al enviar su aplicación para su revisión, debe explicar por escrito por qué su aplicación necesita las secciones solicitadas. Esta explicación debe incluir el tipo de función y el beneficio para el usuario. También es mejor incluir un enlace a su video de YouTube en el envío original para ahorrar mucho en el equipo de revisión.

También se le volverá a preguntar qué correo electrónico debe recibir preguntas de confirmación y notificaciones. Asegúrese de proporcionar una dirección que pueda buscar y recibir correos electrónicos desde fuera de su dominio. Las preguntas se dirigen a la persona que inició la revisión (no necesariamente a los propietarios del proyecto) y a la dirección de correo electrónico de contacto proporcionada en el formulario de revisión. Muchas solicitudes se han retrasado porque el desarrollador no ha respondido a las preguntas del equipo de confirmación.

  Formulario de ejemplo para un proyecto que solicita una revisión

Responder preguntas de revisión

Las aplicaciones con ámbitos confidenciales y restringidos con frecuencia necesitan responder preguntas del equipo de revisión. Si cree que le tomó mucho tiempo obtener una respuesta del equipo de verificación, revise su bandeja de entrada para ver los mensajes "api-oauth-dev-verificación-respuesta" para asegurarse de que no se haya perdido nada.

Seguir estas pautas para enviar su aplicación para su revisión puede simplificar enormemente el proceso de aprobar y compartir su aplicación con la comunidad de usuarios de Google. Si tiene preguntas adicionales, asegúrese de leer las OAuth API Review FAQ .



Software trazabilidad de Cea Ordenadores

Comentarios desactivados en Aprenda a preparar su aplicación para la revisión de OAuth