關於 donde está la biblioteca meaning ，我們在網路上蒐集到這些相關的討論、資訊與評價

... <看更多>

Puedes agregar a tu biblioteca las listas de reproducción que creaste, las de otros creadores y los videos que guardaste en Ver más tarde para encontrarlos ... ... <看更多>

Nota: Si no estás familiarizado con OAuth 2.0, te recomendamos que leas la descripción general de OAuth 2.0 antes de comenzar. En la descripción general, se resumen los flujos de OAuth 2.0 que admite Google, lo que puede ayudarte a asegurarte de haber seleccionado el flujo correcto para tu aplicación.

En este documento, se explica cómo las aplicaciones instaladas en dispositivos como teléfonos, tablets y computadoras usan los extremos de OAuth 2.0 de Google para autorizar el acceso a la API de YouTube Data.

OAuth 2.0 permite que los usuarios compartan datos específicos con una aplicación y, al mismo tiempo, mantengan la privacidad de sus nombres de usuario, contraseñas y otra información.
Por ejemplo, una aplicación puede usar OAuth 2.0 para obtener permiso para subir videos al canal de YouTube de un usuario.

Las apps instaladas se distribuyen a dispositivos individuales y se supone que estas apps no pueden guardar secretos. Pueden acceder a las APIs de Google mientras el usuario está presente en la app o cuando esta se ejecuta en segundo plano.

Este flujo de autorización es similar al que se usa para las aplicaciones de servidor web. La diferencia principal es que las apps instaladas deben abrir el navegador del sistema y proporcionar un URI de redireccionamiento local para controlar las respuestas del servidor de autorización de Google.

Alternativas

En el caso de las aplicaciones para dispositivos móviles, te recomendamos que uses Acceder con Google para Android o iOS. Las bibliotecas cliente de Acceso con Google controlan la autenticación y la autorización del usuario, y pueden ser más fáciles de implementar que el protocolo de nivel inferior que se describe aquí.

En el caso de las apps que se ejecutan en dispositivos que no admiten un navegador del sistema o que tienen capacidades de entrada limitadas, como TVs, consolas de juegos, cámaras o impresoras, consulta OAuth 2.0 para TVs y dispositivos o Cómo acceder en TVs y dispositivos de entrada limitada.

Te recomendamos las siguientes bibliotecas y muestras para ayudarte a implementar el flujo de OAuth 2.0 que se describe en este documento:

Cualquier aplicación que llame a las APIs de Google debe habilitarlas en API Console.

Para habilitar una API en tu proyecto, sigue estos pasos:

Cualquier aplicación que use OAuth 2.0 para acceder a las APIs de Google debe tener credenciales de autorización que identifiquen la aplicación para el servidor OAuth 2.0 de Google. En los siguientes pasos, se explica cómo crear credenciales para tu proyecto. Luego, tus aplicaciones pueden usar las credenciales para acceder a las APIs que habilitaste para ese proyecto.

Los alcances permiten que la aplicación solo solicite acceso a los recursos que necesita, al tiempo que permiten a los usuarios controlar el nivel de acceso que otorgan a tu aplicación. Por lo tanto, puede haber una relación inversa entre la cantidad de permisos solicitados y la probabilidad de obtener el consentimiento del usuario.

Antes de que comiences a implementar la autorización de OAuth 2.0, te recomendamos identificar los alcances para los que la aplicación necesitará permiso de acceso.

La versión 3 de la API de YouTube Data usa los siguientes permisos:

El documento Alcances de la API de OAuth 2.0 contiene una lista completa de los permisos que puedes usar para acceder a las APIs de Google.

En los siguientes pasos, se muestra cómo tu aplicación interactúa con el servidor de OAuth 2.0 de Google para obtener el consentimiento de un usuario y realizar una solicitud a la API en su nombre. Tu aplicación debe tener ese consentimiento para poder ejecutar una solicitud a la API de Google que requiera autorización del usuario.

Google admite el protocolo de clave de prueba para el intercambio de código (PKCE) para que el flujo de la app instalada sea más seguro. Se crea un verificador de código único para cada solicitud de autorización, y su valor transformado, llamado "code_challenge", se envía al servidor de autorización para obtener el código de autorización.

Un code_verifier es una cadena aleatoria criptográfica de alta entropía que usa los caracteres no reservados [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~", con una longitud mínima de 43 caracteres y una longitud máxima de 128 caracteres.

El verificador de códigos debe tener suficiente entropía para que sea poco práctico adivinar el valor.

Se admiten dos métodos para crear el desafío de código.

 code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))

 code_challenge = code_verifier

Para obtener la autorización del usuario, envía una solicitud al servidor de autorización de Google en https://accounts.google.com/o/oauth2/v2/auth. Este extremo controla la búsqueda de sesiones activas, autentica al usuario y obtiene su consentimiento. Solo se puede acceder al extremo a través de SSL, y se rechazan las conexiones HTTP (no SSL).

El servidor de autorización admite los siguientes parámetros de cadena de consulta para las aplicaciones instaladas:

El ID de cliente de tu aplicación. Puedes encontrar este valor en el de .

Determina cómo el servidor de autorización de Google envía una respuesta a tu app. Existen varias opciones de redireccionamiento disponibles para las apps instaladas, y habrás configurado tus credenciales de autorización teniendo en cuenta un método de redireccionamiento en particular.

El valor debe coincidir exactamente con uno de los URIs de redireccionamiento autorizados para el cliente de OAuth 2.0, que configuraste en el de tu cliente . Si este valor no coincide con un URI autorizado, recibirás un error redirect_uri_mismatch.

En la siguiente tabla, se muestra el valor correcto del parámetro redirect_uri para cada método:

o

Consulta a tu plataforma la dirección IP de bucle invertido relevante y, luego, inicia un objeto de escucha HTTP en un puerto disponible aleatorio. Reemplaza port por el número de puerto en el que la app escucha.

Ten en cuenta que la compatibilidad con la opción de redireccionamiento de la dirección IP de bucle invertido en las aplicaciones para dispositivos móviles está
OBSOLETA.

Determina si el extremo de Google OAuth 2.0 muestra un código de autorización.

Establece el valor del parámetro en code para las aplicaciones instaladas.

Es una lista de permisos delimitados por espacios que identifican los recursos a los que puede acceder tu aplicación en nombre del usuario. Estos valores informan la pantalla de consentimiento que Google muestra al usuario.

Los alcances permiten que la aplicación solo solicite acceso a los recursos que necesita, al tiempo que permiten a los usuarios controlar el nivel de acceso que otorgan a tu aplicación. Por lo tanto, existe una relación inversa entre la cantidad de permisos solicitados y la probabilidad de obtener el consentimiento del usuario.

La versión 3 de la API de YouTube Data usa los siguientes permisos:

El documento Alcances de la API de OAuth 2.0 proporciona una lista completa de los permisos que puedes usar para acceder a las APIs de Google.

Especifica un code_verifier codificado que se usará como desafío del servidor durante el intercambio de códigos de autorización. Consulta la sección Crea un desafío de código anterior para obtener más información.

Especifica qué método se usó para codificar un code_verifier que se usará
durante el intercambio de códigos de autorización. Este parámetro se debe usar con el parámetro code_challenge descrito anteriormente. El valor de code_challenge_method se establece de forma predeterminada en plain si no está presente en la solicitud que incluye un code_challenge. Los únicos valores admitidos para este parámetro son S256 o plain.

Especifica cualquier valor de cadena que use tu aplicación para mantener el estado entre tu solicitud de autorización y la respuesta del servidor de autorización.
El servidor muestra el valor exacto que envías como un par name=value en el identificador de fragmento de URL (#) de redirect_uri después de que el usuario acepta o rechaza la solicitud de acceso de tu aplicación.

Puedes usar este parámetro para varios fines, como dirigir al usuario al recurso correcto en tu aplicación, enviar nonces y mitigar la falsificación de solicitudes entre sitios. Dado que se puede adivinar tu redirect_uri, usar un valor state puede aumentar tu seguridad de que una conexión entrante es el resultado de una solicitud de autenticación. Si generas una cadena aleatoria o codificas el hash de una cookie o otro valor que capture el estado del cliente, puedes validar la respuesta para asegurarte además de que la solicitud y la respuesta se originen en el mismo navegador, lo que proporciona protección contra ataques como la falsificación de solicitudes entre sitios. Consulta la documentación de
OpenID Connect
para ver un ejemplo de cómo crear y confirmar un token state.

Si tu aplicación sabe qué usuario intenta autenticarse, puede usar este parámetro para proporcionar una sugerencia al servidor de autenticación de Google. El servidor usa la sugerencia para simplificar el flujo de acceso, ya sea completando previamente el campo de correo electrónico en el formulario de acceso o seleccionando la sesión de acceso múltiple adecuada.

Establece el valor del parámetro en una dirección de correo electrónico o un identificador sub, que es equivalente al ID de Google del usuario.

En las siguientes pestañas, se muestran ejemplos de URLs de autorización para las diferentes opciones de URI de redireccionamiento.

Las URLs son idénticas, excepto por el valor del parámetro redirect_uri. Las URLs también contienen los parámetros response_type y client_id obligatorios, así como el parámetro state opcional. Cada URL contiene saltos de línea y espacios para facilitar la lectura.

https://accounts.google.com/o/oauth2/v2/auth?
  scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.readonly&
  response_type=code&
  state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
  redirect_uri=com.example.app%3A/oauth2redirect&
  client_id=client_id

https://accounts.google.com/o/oauth2/v2/auth?
  scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.readonly&
  response_type=code&
  state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
  redirect_uri=http%3A//127.0.0.1%3A9004&
  client_id=client_id

En este paso, el usuario decide si otorgarle a tu aplicación el acceso solicitado. En esta etapa, Google muestra una ventana de consentimiento que muestra el nombre de tu aplicación y los servicios de la API de Google a los que solicita permiso para acceder con las credenciales de autorización del usuario, y un resumen de los permisos de acceso que se otorgarán. Luego, el usuario puede consentir otorgar acceso a uno o más permisos solicitados por tu aplicación o rechazar la solicitud.

Tu aplicación no necesita hacer nada en esta etapa, ya que espera la respuesta del servidor de OAuth 2.0 de Google que indique si se otorgó algún acceso. Esa respuesta se explica en el siguiente paso.

Es posible que las solicitudes al extremo de autorización de OAuth 2.0 de Google muestren mensajes de error para el usuario en lugar de los flujos de autenticación y autorización esperados. A continuación, se indican los códigos de error comunes y las resoluciones sugeridas.

La Cuenta de Google no puede autorizar uno o más permisos solicitados debido a las políticas de su administrador de Google Workspace. Consulta el artículo de ayuda del administrador de Google Workspace
Controla qué apps internas y de terceros acceden a los datos de Google Workspace para obtener más información sobre cómo un administrador puede restringir el acceso a todos los permisos o a los permisos sensibles y restringidos hasta que se otorgue acceso de forma explícita a tu ID de cliente de OAuth.

El extremo de autorización se muestra dentro de un usuario-agente incorporado que no está permitido según las Políticas de OAuth 2.0 de Google.

Es posible que los desarrolladores de Android encuentren este mensaje de error cuando abran solicitudes de autorización en android.webkit.WebView.
En su lugar, los desarrolladores deben usar bibliotecas de Android, como Acceso con Google para Android o AppAuth para Android de la OpenID Foundation.

Es posible que los desarrolladores web encuentren este error cuando una app para Android abre un vínculo web general en un usuario-agente incorporado y un usuario navega al extremo de autorización de OAuth 2.0 de Google desde tu sitio. Los desarrolladores deben permitir que los vínculos generales se abran en el controlador de vínculos predeterminado del sistema operativo, que incluye los controladores de Android App Links o la app de navegador predeterminada. La biblioteca de Android Custom Tabs también es una opción compatible.

Es posible que los desarrolladores de iOS y macOS encuentren este error cuando abran solicitudes de autorización en WKWebView.
En su lugar, los desarrolladores deben usar bibliotecas de iOS, como Acceso con Google para iOS o AppAuth para iOS de OpenID Foundation.

Es posible que los desarrolladores web encuentren este error cuando una app para iOS o macOS abre un vínculo web general en un usuario-agente incorporado y un usuario navega al extremo de autorización de OAuth 2.0 de Google desde tu sitio. Los desarrolladores deben permitir que los vínculos generales se abran en el controlador de vínculos predeterminado del sistema operativo, que incluye los controladores de vínculos universales o la app de navegador predeterminada. La biblioteca SFSafariViewController también es una opción compatible.

El ID de cliente de OAuth en la solicitud forma parte de un proyecto que limita el acceso a las Cuentas de Google en una
organización de Google Cloud específica.
Para obtener más información sobre esta opción de configuración, consulta la sección Tipo de usuario en el artículo de ayuda Cómo configurar tu pantalla de consentimiento de OAuth.

Si usas un verificador de código y un desafío, el parámetro code_callenge no es válido o falta. Asegúrate de que el parámetro code_challenge esté configurado correctamente.

Cuando se actualiza un token de acceso, es posible que el token haya caducado o que se haya invalidado.
Vuelve a autenticar al usuario y solicita su consentimiento para obtener tokens nuevos. Si sigues viendo este error, asegúrate de que tu aplicación esté configurada correctamente y de que uses los tokens y parámetros correctos en tu solicitud. De lo contrario, es posible que se haya borrado o inhabilitado la cuenta de usuario.

El redirect_uri que se pasó en la solicitud de autorización no coincide con un URI de redireccionamiento autorizado para el ID de cliente de OAuth. Revisa los URI de redireccionamiento autorizados en
.

Es posible que el redirect_uri pasado no sea válido para el tipo de cliente.

El parámetro redirect_uri puede hacer referencia al flujo fuera de banda (OOB) de OAuth que dejó de estar disponible y ya no es compatible. Consulta la guía de migración para actualizar tu integración.

Se produjo un error con la solicitud que realizaste. Esto puede deberse a varios motivos:

La forma en que tu aplicación recibe la respuesta de autorización depende del esquema de URI de redireccionamiento que usa. Independientemente del esquema, la respuesta contendrá un código de autorización (code) o un error (error). Por ejemplo, error=access_denied indica que el usuario rechazó la solicitud.

Si el usuario otorga acceso a tu aplicación, puedes intercambiar el código de autorización por un token de acceso y un token de actualización, como se describe en el siguiente paso.

Para intercambiar un código de autorización por un token de acceso, llama al extremo https://oauth2.googleapis.com/token y establece los siguientes parámetros:

En el siguiente fragmento, se muestra una solicitud de muestra:

POST /token HTTP/1.1
 Host: oauth2.googleapis.com
 Content-Type: application/x-www-form-urlencodedcode=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&
 client_id=your_client_id&
 client_secret=your_client_secret&
 redirect_uri=http://127.0.0.1:9004&
 grant_type=authorization_code

Google responde a esta solicitud mostrando un objeto JSON que contiene un token de acceso de corta duración y un token de actualización.

La respuesta contiene los siguientes campos:

En el siguiente fragmento, se muestra una respuesta de ejemplo:

{
   "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
   "expires_in": 3920,
   "token_type": "Bearer",
   "scope": "https://www.googleapis.com/auth/youtube.force-ssl",
   "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
 }

Cuando solicitas varios permisos (alcances), es posible que los usuarios no otorguen a tu app acceso a todos ellos. Tu app debe verificar qué permisos se otorgaron y controlar de forma fluida las situaciones en las que se deniegan algunos permisos, por lo general, inhabilitando las funciones que dependen de esos permisos denegados.

Sin embargo, hay algunas excepciones. Las apps de Google Workspace Enterprise con delegación de autoridad de todo el dominio o las apps marcadas como Confiable omiten la pantalla de consentimiento de permisos detallados. En el caso de estas apps, los usuarios no verán la pantalla de consentimiento de permisos detallados. En su lugar, tu app recibirá todos los permisos solicitados o ninguno.

Para obtener información más detallada, consulta Cómo controlar permisos detallados.

Para verificar si el usuario otorgó a tu aplicación acceso a un alcance en particular, examina el campo scope en la respuesta del token de acceso. Los permisos de acceso otorgados por el access_token expresados como una lista de cadenas separadas por espacios y sensibles a mayúsculas y minúsculas.

Por ejemplo, la siguiente respuesta de muestra del token de acceso indica que el usuario le otorgó permiso a tu aplicación para ver, editar y borrar de forma permanente sus videos, calificaciones, comentarios y subtítulos de YouTube:

  {
     "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
     "expires_in": 3920,
     "token_type": "Bearer",
     "scope": "https://www.googleapis.com/auth/youtube.force-ssl",
     "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
   }

Una vez que tu aplicación obtenga un token de acceso, podrás usarlo para realizar llamadas a una API de Google en nombre de una cuenta de usuario determinada si se otorgaron los permisos de acceso que requiere la API. Para ello, incluye el token de acceso en una solicitud a la API, ya sea con un parámetro de consulta access_token o un valor Bearer de encabezado HTTP Authorization. Cuando sea posible, se prefiere el encabezado HTTP, ya que las cadenas de consulta suelen ser visibles en los registros del servidor. En la mayoría de los casos, puedes usar una biblioteca cliente para configurar tus llamadas a las APIs de Google (por ejemplo, cuando llamas a la API de YouTube Data).

Ten en cuenta que la API de YouTube Data admite cuentas de servicio solo para propietarios de contenido de YouTube que poseen y administran varios canales de YouTube, como sellos discográficos y estudios cinematográficos.

Puedes probar todas las APIs de Google y ver sus permisos en OAuth 2.0 Playground.

Una llamada al extremo
youtube.channels (la API de datos de YouTube) con el encabezado HTTP Authorization: Bearer podría verse de la siguiente manera. Ten en cuenta que debes especificar tu propio token de acceso:

 GET /youtube/v3/channels?part=snippet&mine=true HTTP/1.1
 Host: www.googleapis.com
 Authorization: Bearer access_token

Esta es una llamada a la misma API para el usuario autenticado con el parámetro de cadena de consulta access_token:

 GET https://www.googleapis.com/youtube/v3/channels?access_token=access_token&part=snippet&mine=true

Puedes probar estos comandos con la aplicación de línea de comandos curl. A continuación, se muestra un ejemplo que usa la opción de encabezado HTTP (preferida):

 curl -H "Authorization: Bearer access_token" https://www.googleapis.com/youtube/v3/channels?part=snippet&mine=true

O bien, la opción de parámetro de cadena de consulta:

 curl https://www.googleapis.com/youtube/v3/channels?access_token=access_token&part=snippet&mine=true

Los tokens de acceso vencen periódicamente y se convierten en credenciales no válidas para una solicitud a la API relacionada. Puedes actualizar un token de acceso sin solicitarle permiso al usuario (incluso cuando no está presente) si solicitaste acceso sin conexión a los permisos asociados con el token.

Para actualizar un token de acceso, tu aplicación envía una solicitud POST HTTPS al servidor de autorización de Google (https://oauth2.googleapis.com/token) que incluye los siguientes parámetros:


Campos




client_id
El ID de cliente obtenido de API Console.


client_secret
El secreto de cliente obtenido de API Console

(client_secret no se aplica a las solicitudes de clientes registrados como aplicaciones para Android, iOS o Chrome).




grant_type
Como
se define en la
especificación de OAuth 2.0,
el valor de este campo debe establecerse en refresh_token.


refresh_token
El token de actualización que se muestra después del intercambio de códigos de autorización.

En el siguiente fragmento, se muestra una solicitud de muestra:

 POST /token HTTP/1.1
 Host: oauth2.googleapis.com
 Content-Type: application/x-www-form-urlencodedclient_id=your_client_id&
 client_secret=your_client_secret&
 refresh_token=refresh_token&
 grant_type=refresh_token

Siempre que el usuario no haya revocado el acceso otorgado a la aplicación, el servidor de tokens muestra un objeto JSON que contiene un token de acceso nuevo. En el siguiente fragmento, se muestra una respuesta de ejemplo:

{
   "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
   "expires_in": 3920,
   "scope": "https://www.googleapis.com/auth/drive.metadata.readonly",
   "token_type": "Bearer"
 }

Ten en cuenta que hay límites en la cantidad de tokens de actualización que se emitirán: un límite por combinación de cliente/usuario y otro por usuario en todos los clientes. Debes guardar los tokens de actualización
en el almacenamiento a largo plazo y seguir usándolos mientras sigan siendo válidos. Si tu aplicación solicita demasiados tokens de actualización, es posible que se encuentre con estos límites, en cuyo caso los tokens de actualización más antiguos dejarán de funcionar.

En algunos casos, es posible que un usuario desee revocar el acceso otorgado a una aplicación. Para revocar el acceso, el usuario puede ir a
Configuración de la cuenta. Para obtener más información, consulta la sección Cómo quitar el acceso de un sitio o una app del documento de asistencia Sitios y apps de terceros con acceso a tu cuenta.

También es posible que una aplicación revoque de forma programática el acceso que se le otorgó.
La revocación programática es importante en los casos en que un usuario cancela su suscripción, quita una aplicación o los recursos de la API que requiere una app cambiaron de forma significativa. En otras palabras, parte del proceso de eliminación puede incluir una solicitud a la API para garantizar que se quiten los permisos otorgados anteriormente a la aplicación.

Para revocar un token de manera programática, tu aplicación envía una solicitud a https://oauth2.googleapis.com/revoke y, además, incluye el token como parámetro:

 curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded" \
         https://oauth2.googleapis.com/revoke?token={token}

El token puede ser un token de acceso o un token de actualización. Si el token es un token de acceso y tiene un token de actualización correspondiente, este también se revocará.

Si la revocación se procesa correctamente, el código de estado HTTP de la respuesta es 200. Para las condiciones de error, se muestra un código de estado HTTP 400 junto con un código de error.

Los esquemas de URI personalizados son una forma de vinculación directa que usa un esquema definido por el usuario para abrir tu app.

Usa el SDK de Acceso con Google para Android, que envía la respuesta de OAuth 2.0 directamente a tu app, lo que elimina la necesidad de un URI de redireccionamiento.

Si usas un esquema personalizado para tu integración de OAuth en Android, deberás completar las siguientes acciones para migrar por completo al uso del SDK recomendado de Acceso con Google para Android:

Sigue estos pasos para migrar al SDK de Android de Acceso a Google:

   https://accounts.google.com/o/oauth2/v2/auth?
   scope=<SCOPES>&
   response_type=code&
   &state=<STATE>&
   redirect_uri=com.example.app:/oauth2redirect&
   client_id=<CLIENT_ID>
   

Usa la API de Chrome Identity, que envía la respuesta de OAuth 2.0 directamente a tu app, lo que elimina la necesidad de un URI de redireccionamiento.

Para recibir el código de autorización con esta URL, tu aplicación debe estar escuchando en el servidor web local. Eso es posible en muchas plataformas, pero no en todas. Sin embargo, si tu plataforma lo admite, este es el mecanismo recomendado para obtener el código de autorización.

Cuando tu app recibe la respuesta de autorización, para una mejor usabilidad, debe mostrar una página HTML que le indique al usuario que cierre el navegador y regrese a tu app.

Puedes verificar la propiedad de tu aplicación para reducir el riesgo de suplantación de identidad.

La función de Verificación de aplicaciones ayuda a proteger tus aplicaciones para iOS del uso no autorizado mediante el servicio de App Attest de Apple para verificar que las solicitudes que se realizan a los extremos de OAuth 2.0 de Google provengan de tus aplicaciones auténticas. Esto ayuda a reducir el riesgo de suplantación de identidad de apps.

Después de habilitar la Verificación de aplicaciones, comenzarás a ver métricas relacionadas con las solicitudes de OAuth de tu cliente en la vista de edición del cliente de OAuth. Las solicitudes de fuentes no verificadas no se bloquearán hasta que apliques la Verificación de aplicaciones. La información de la página de supervisión de métricas puede ayudarte a determinar cuándo comenzar la aplicación forzosa.

Es posible que veas errores relacionados con la función de Verificación de apps cuando habilites esta función para tu app para iOS. Para solucionar estos errores, haz lo siguiente:

Para aplicar la Verificación de aplicaciones, haz clic en el botón APPLICAR y confirma tu elección. Una vez que la aplicación forzosa esté activa, se rechazarán todas las solicitudes no verificadas de tu cliente.

Nota: Después de habilitar la aplicación forzosa, los cambios pueden tardar hasta 15 minutos en aplicarse.

Si anulas la aplicación de la Verificación de aplicaciones para tu app, se detendrá la aplicación y se permitirán todas las solicitudes de tu cliente a los extremos de OAuth 2.0 de Google, incluidas las solicitudes no verificadas.

Para inhabilitar la Verificación de aplicaciones en tu cliente para iOS, navega a la vista de edición del cliente para iOS, haz clic en el botón DESACTIVAR y confirma tu elección.

Nota: Después de inhabilitar la Verificación de apps, los cambios pueden tardar hasta 15 minutos en aplicarse.

Si inhabilitas la Verificación de aplicaciones en tu app, se detendrá toda la supervisión y la aplicación forzosa. Considera anular la Verificación de aplicaciones para que puedas seguir supervisando las métricas de tu cliente.

Para inhabilitar la Verificación de aplicaciones en tu cliente para iOS, navega a la vista de edición del cliente para iOS y desactiva el botón de activación Protege tu cliente de OAuth contra abusos con la Verificación de aplicaciones de Firebase.

Nota: Después de inhabilitar la Verificación de aplicaciones, los cambios pueden tardar hasta 15 minutos en aplicarse.

En la práctica recomendada actual del IETF OAuth 2.0 para apps nativas, se establecen muchas de las prácticas recomendadas que se documentan aquí.

Un paso adicional que debes seguir para proteger las cuentas de tus usuarios es implementar la Protección entre cuentas con el servicio de Protección entre cuentas de Google. Este servicio te permite suscribirte a notificaciones de eventos de seguridad que proporcionan información a tu aplicación sobre cambios importantes en la cuenta del usuario. Luego, puedes usar la información para tomar medidas según cómo decidas responder a los eventos.

Estos son algunos ejemplos de los tipos de eventos que el servicio de Protección entre cuentas de Google envía a tu app:

Consulta la página
Protege las cuentas de usuario con la Protección integral de la cuenta
para obtener más información sobre cómo implementar la Protección integral de la cuenta y ver la lista completa de eventos disponibles.