LinkedIn
Instagram
WhatsApp
Telegrama
Gmail
Outlook
Calendario de Google
Únase a la comunidad SlackEn Google OAuth Playground es la herramienta sandbox oficial de Google para probar flujos de autorización OAuth 2.0 sin escribir una sola línea de código backend. Esta guía te guía a través de cada función: seleccionar alcances, intercambiar códigos de autorización por tokens, realizar llamadas API en vivo y comprender cuándo necesitas pasar del playground a una solución de nivel de producción.
¿Qué es el Google OAuth Playground?
En Google OAuth Playground es una herramienta gratuita basada en el navegador en developers.google.com/oauthplayground que permite a los desarrolladores probar el flujo de autorización OAuth 2.0 completo contra cualquier API de Google sin configurar un servidor backend, registrar una aplicación o escribir código del lado del servidor.
En esencia, esta herramienta es una interfaz visual para el flujo OAuth 2.0 de tres patas. Seleccionas los ámbitos de la API de Google que deseas, haces clic en "Autorizar APIs", completas la pantalla de consentimiento de Google y luego intercambias el código de autorización resultante por un token de acceso y un token de actualización. A partir de ese momento, puedes realizar solicitudes de API autenticadas directamente dentro del navegador e inspeccionar las cargas útiles de solicitud y respuesta sin procesar.
Es particularmente útil para equipos que crean sobre Gmail, Google Calendar, Google Drive o cualquier otra API de Google Workspace. En lugar de depurar flujos de tokens en producción, puede probar todo en un entorno seguro de "sandbox" primero. El entorno de juegos de OAuth 2.0 de Google admite todos los ámbitos de OAuth de Google publicados y muestra las cabeceras HTTP y las cargas útiles JSON exactas en cada paso del flujo.
Por qué los desarrolladores usan el Google OAuth Playground
El Playground de OAuth 2.0 resuelve cuatro problemas específicos para los desarrolladores. Comprender cuál se aplica a ti te ayudará a sacar el máximo provecho de cada sesión y a saber cuándo pasar a una configuración de producción.
Antes de enviar tu aplicación, necesitas saber exactamente qué ámbito de OAuth otorga acceso a qué datos. El entorno de pruebas te permite comparar gmail.lectura vs gmail.modificar vs gmail.enviar lado a lado, llamando a la API real de Gmail e inspeccionando qué expone cada ámbito. Esto evita el sobre-permiso (solicitar demasiados ámbitos, lo que genera más escrutinio por parte del equipo de revisión de Google) y el sub-permiso (solicitar muy pocos, lo que causa errores en tiempo de ejecución para sus usuarios).
Configurar un flujo de redireccionamiento OAuth completo a nivel local lleva tiempo: se necesita un servidor HTTP, una URL de devolución de llamada, gestión de sesiones y almacenamiento de tokens. El entorno de pruebas evita todo esto. Te autentificas una vez en el navegador, obtienes tus tokens y, a continuación, ejecutas cualquier punto final de la API de Google directamente desde el panel "Enviar la solicitud". Esto resulta especialmente útil para depurar errores 403 inesperados o comprender la estructura de las respuestas de la API antes de escribir la lógica de análisis en tu aplicación.
La zona de juegos es una de las mejores herramientas de aprendizaje disponibles para comprender cómo funciona realmente OAuth 2.0. La interfaz de usuario paso a paso hace que el flujo abstracto sea concreto: ves la URL de autorización construida con los ámbitos que elegiste, ves el código de autorización devuelto en la redirección y ves cómo ese código se intercambia por un token de acceso y un token de actualización. Para los equipos que incorporan ingenieros nuevos en OAuth, una sesión de 30 minutos en la zona de juegos reemplaza horas de lectura de documentación. Consulte nuestra guía sobre integrando Google OAuth 2.0 en tu aplicación para la implementación de producción completa.
A veces solo necesitas un token de acceso válido para ejecutar un script de migración de datos único, probar la carga útil de un webhook o verificar manualmente una integración de API. La consola genera un token de acceso funcional en menos de 60 segundos. Cópialo, pégalo en tu comando curl o Postman y listo. La advertencia es que los tokens de la consola (que utilizan las credenciales predeterminadas de Google) caducan después de 24 horas para el token de actualización, y el token de acceso expira después de 1 hora, por lo que este enfoque se limita a scripts de corta duración.
Inicio rápido: Tu primera sesión de Playground en 3 minutos
Sigue estos cinco pasos para pasar de cero a una llamada de API funcional dentro del playground. No se requiere configuración de Google Cloud Console para este flujo básico.
Abrir developers.google.com/oauthplayground en tu navegador. Verás la interfaz principal dividida en tres secciones: Paso 1 (Seleccionar y autorizar APIs), Paso 2 (Intercambiar código de autorización por tokens) y Paso 3 (Configurar la solicitud a la API). En el lado derecho se encuentra el panel de configuración de OAuth 2.0, accesible a través del icono del engranaje. Asegúrate de haber iniciado sesión en tu cuenta de Google antes de continuar.
En el panel Paso 1, desplázate por la lista de API de Google o usa el cuadro de búsqueda. Haz clic en Gmail API v1 para expandirlo. Seleccionar https://www.googleapis.com/auth/gmail.readonly para empezar con acceso de solo lectura. Puedes seleccionar múltiples ámbitos de múltiples API en una sola sesión; todos se agruparán en una única solicitud de autorización. Una vez que hayas seleccionado tu(s) ámbito(s), haz clic en el botón azul "Autorizar APIs" botón.
Serás redirigido a la pantalla de consentimiento de Google. Es la misma Pantalla de consentimiento de OAuth sus usuarios finales verán en su aplicación de producción; la consola de pruebas simplemente usa el nombre de la aplicación de Google en lugar del suyo. Seleccione su cuenta de Google, revise los permisos solicitados y haga clic en "Permitir". Google lo redirigirá de regreso a la consola de pruebas con un código de autorización en la URL.
Ya estás en el Paso 2. El entorno de pruebas ha capturado automáticamente el código de autorización. Haz clic "Canjear código de autorización por tokens". El patio de recreo envía una solicitud POST a https://oauth2.googleapis.com/token y muestra tanto la solicitud sin procesar como la respuesta. Verás tu token_de_acceso (válido durante 1 hora) y tu token de actualización en el panel de respuesta. Anota estos si necesitas reutilizarlos fuera del playground.
En el Paso 3, ingrese el punto final de la API de Gmail en el campo "URI de solicitud": https://gmail.googleapis.com/gmail/v1/users/me/messages. Dejar el método HTTP como GET y haz clic en "Enviar la solicitud". El playground inserta automáticamente tu token de acceso como una cabecera Bearer. El panel de respuesta muestra la carga útil JSON de la API de Gmail, una lista de IDs de mensajes de tu bandeja de entrada. Acabas de completar un flujo completo de OAuth 2.0 en el playground.
Paso a paso: cómo probar los ámbitos de OAuth en el Google OAuth Playground
La selección del alcance es la decisión más importante en tu integración de OAuth. Demasiado amplio y el equipo de revisión de Google marcará tu aplicación. Demasiado estrecho y tus llamadas a la API devolverán errores 403. El playground te permite probar cada combinación antes de comprometerte. Para una referencia completa de cada alcance de Gmail, consulta nuestro Guía de ámbitos de la API de Gmail.
gmail.lectura antes de probar gmail.modificar. Este principio de privilegio mínimo reduce la superficie de ataque de su aplicación y simplifica la revisión de seguridad de Google. Más información sobre el proceso de revisión: Guía de verificación de Google OAuth.| Alcance | Nivel de acceso | Sensibilidad | Caso práctico |
|---|---|---|---|
gmail.lectura |
Leer todos los mensajes y ajustes | Sensible | Analíticas de correo electrónico, sincronización de la bandeja de entrada |
gmail.modificar |
Leer, modificar etiquetas, eliminar mensajes | Restringido | Integración de CRM, aplicaciones de triaje |
gmail.enviar |
Enviar solo mensajes | Restringido | Envío transaccional en nombre del usuario |
gmail.redactar |
Crear, leer, actualizar y eliminar borradores | Sensible | Asistentes de IA para correos electrónicos, gestión de borradores |
gmail.etiquetas |
Crear, leer, actualizar y eliminar etiquetas | Sensible | Automatización de etiquetas, herramientas de organización |
metadatos de gmail |
Leer solo metadatos del mensaje (encabezados, etiquetas) | No sensible | Indicadores de presencia de correo electrónico, seguimiento de hilos |
La zona de pruebas funciona igual de bien para la prueba de la API de Calendar. Para probar el acceso de lectura del calendario, selecciona https://www.googleapis.com/auth/calendar.readonly. Para acceso completo de lectura/escritura, incluida la creación y eliminación de eventos, utiliza https://www.googleapis.com/auth/calendar. Los alcances del calendario siguen el mismo patrón: empieza con solo lectura, luego escala solo si necesitas operaciones de escritura. Un error común es solicitar el completo calendario ámbito cuando solo se necesita leer la disponibilidad; esto desencadena innecesariamente una revisión de seguridad más invasiva.
La zona de juegos también acepta URL de alcance personalizadas que no se encuentran en el menú predeterminado. En el panel Paso 1, busque el campo "Ingresar sus propios alcances" en la parte inferior. Pegue cualquier URL de alcance válida, por ejemplo, un alcance del SDK de administración de Google Workspace o un alcance de la API de Google People, y se agregará a la solicitud de autorización junto con los alcances que haya seleccionado de la lista. Esto es útil para probar API de Google menos comunes que no se destacan en la interfaz de usuario de la zona de juegos.
Integra Gmail con UnipilePaso a paso: Generación de tokens de acceso y tokens de actualización
El Paso 2 del Playground es donde ocurre la verdadera magia de OAuth. Después de que autorizas, un código de autorización permanece en el playground esperando ser canjeado. Esta sección explica los dos tokens que recibes, cómo forzar un token de actualización y cómo replicar el canje en tu código de producción.
En token de acceso es una credencial de corta duración (3600 segundos por defecto) utilizada como token de portador en el Authorization encabezado de cada solicitud a la API. Cuando expira, la API devuelve un error 401. Usas el token de actualización para obtener un nuevo token de acceso sin que el usuario tenga que volver a autorizar. En el "playground", el botón "Refresh access token" hace esto automáticamente en el Paso 2.
En token de actualización es una credencial de larga duración que permite a tu aplicación obtener nuevos tokens de acceso sin la interacción del usuario. Nunca expira en producción (a menos que el usuario lo revoque o la aplicación haya estado inactiva durante 6 meses). Sin embargo, en el entorno de prueba, utilizando las credenciales predeterminadas de Google, los tokens de actualización expiran después de 24 horas. Esta es una limitación específica del entorno de prueba, no una limitación de producción.
Por defecto, Google solo devuelve un token de actualización primera vez un usuario autoriza tu aplicación. En autorizaciones posteriores (si el usuario ya ha consentido), Google omite el token de actualización. Para forzar que el patio de recreo siempre devuelva un token de actualización en el Paso 2, haz clic en el ícono del engranaje para abrir la configuración de OAuth 2.0 y habilita ambos "Forzar indicación" y "Tipo de acceso: sin conexión". Con estas configuraciones, cada flujo de autorización devuelve un nuevo token de actualización.
La zona de juegos le muestra la solicitud POST exacta que envía para intercambiar el código de autorización. Puede replicar este comando curl directamente en su backend:
Advertencia sobre el token de actualización de 24 horas: cuando utilizas las credenciales predeterminadas de Google del playground (la configuración más común), Google limita la vida útil del token de actualización a 24 horas. Esto es intencional: el playground utiliza un único cliente OAuth compartido, y Google revoca los tokens con frecuencia por motivos de seguridad. Si necesitas un token de actualización que dure más de 24 horas, habilita "Usar tus propias credenciales de OAuth" en la configuración del playground, que se explica en la siguiente sección.
Usando tus propias credenciales OAuth en Google OAuth Playground
La configuración predeterminada del playground utiliza las credenciales de desarrollador compartidas de Google, lo que provoca la caducidad del token de actualización de 24 horas. Cambiar a tu propio ID de cliente OAuth resuelve esto y hace que el comportamiento del playground sea idéntico al de tu aplicación de producción. Este es el enfoque correcto cuando necesitas probar Diferencias entre clave de API y OAuth o trabajar a través del completo Flujo de integración de Google OAuth.
https://developers.google.com/oauthplayground. Este es el URI de redirección específico que espera el playground.gmail.modificar) requiere una app verificada. Con tus propias credenciales, puedes probar en modo de desarrollo con hasta 100 usuarios de prueba sin pasar por una verificación completa.client_id, secreto_clientey uri_redireccionamiento tu backend de producción utilizará. Puedes copiar el código de intercambio directamente en tu aplicación.https://developers.google.com/oauthplayground/ pero el playground redirige a la URL sin la barra, obtendrás un redirect_uri_mismatch error. Agrega ambas versiones si no estás seguro. Para una mirada más profunda a los códigos de error de Google, consulta nuestra guía sobre errores comunes de Google OAuth.Puntos débiles comunes en Google OAuth Playground
Estos son los seis errores y trampas que confunden a los desarrolladores con mayor frecuencia en el playground. Cada uno tiene una solución específica que toma menos de 2 minutos para aplicar.
Al usar las credenciales predeterminadas del playground de Google, tu token de actualización se vuelve inválido después de 24 horas. Cualquier script o integración que dependa de este token comenzará a devolver 401 concesión_inválida errores al día siguiente.
Cuando usa sus propias credenciales, Google devuelve error=redirect_uri_mismatch durante el paso de autorización. Esto significa que la URI de redireccionamiento en tu cliente OAuth de la Consola de Google Cloud no coincide exactamente con lo que envía el entorno de pruebas.
https://developers.google.com/oauthplayground (sin barra final) como URI de redirección autorizada. Consulta nuestra guía sobre Errores de OAuth para más.La llamada API en el Paso 3 devuelve 403 permisos insuficientes. Esto ocurre cuando llamas a un endpoint que requiere un ámbito que no incluiste en el Paso 1, o cuando olvidaste hacer clic en "Autorizar APIs" después de agregar un nuevo ámbito.
Los tokens de acceso solo son válidos durante 3600 segundos. Si tu sesión de prueba se alarga, las llamadas en el Paso 3 comenzarán a fallar. Credenciales no válidas aunque tu token de actualización todavía sea válido.
Algunas API de Google tienen requisitos de alcance versionado. Por ejemplo, la API de Google Calendar v3 utiliza URL base diferentes a las de versiones anteriores. El uso de un alcance diseñado para v1 en un punto final de v3 puede generar errores inesperados o datos incompletos.
Ve errores relacionados con CORS en DevTools al usar la función "Enviar la solicitud" del playground desde ciertos entornos de red (proxies corporativos, VPN). Este es un comportamiento del navegador específico del playground, no un problema de la API de Google.
Parque de pruebas vs. Producción: Cuando te quedas corto para el Playground de Google OAuth
El playground es una excelente herramienta de prueba, no está diseñado para uso en producción. Aquí hay una comparación honesta de lo que cambia al pasar de las pruebas en el playground a una integración OAuth real que atiende a usuarios reales.
| Característica | OAuth Playground | Aplicación de Producción |
|---|---|---|
| Vida útil del token de actualización | 24h máximo (con las credenciales de Google) Ilimitado con credenciales propias |
Sin límites hasta que el usuario revoque o 6 meses de inactividad |
| Base de usuarios | 1 usuario (solo tu cuenta de Google) | N usuarios - cualquier número de cuentas de Google puede autorizar tu aplicación |
| Verificación de OAuth | No es necesario - el playground omite la revisión | Requerido después de 100 usuarios de prueba, para alcances restringidos |
| Revisión de seguridad Nivel 2 de CASA | No aplicable - el playground es una herramienta propia de Google | Requerido para aplicaciones que solicitan ámbitos restringidos de Gmail o Calendar |
| Pantalla de consentimiento de marca | Muestra "Google OAuth 2.0 Playground" como el nombre de la aplicación | Muestra el nombre de tu aplicación, su logotipo y tu política de privacidad |
| Visibilidad de solicitud / respuesta | Visibilidad total - ver todas las cabeceras HTTP y la carga útil | Oculto para los usuarios finales: solo tu backend ve los tokens sin procesar y las respuestas de la API |
| Límites de la API | Cuotas estándar de la API de Google (compartidas con otros usuarios del playground cuando se usan las credenciales de Google) | Cuota dedicada de tu propio proyecto: sin compartir con otros desarrolladores |
| Caso de uso previsto | Prueba, depuración, aprendizaje, generación de tokens únicos | Servir a usuarios finales a escala con gestión de tokens persistente y multiusuario |
La regla general: usa el entorno de pruebas hasta que se confirme tu lógica de integración, luego pasa a un flujo de OAuth de producción para cualquier elemento visible para el usuario. El mayor punto de fricción en producción es el proceso de verificación de Google: para las aplicaciones que solicitan ámbitos sensibles o restringidos, esto puede llevar semanas. Es ahí donde una solución como Unipile puede ayudar: utiliza credenciales pre-verificadas y omite la revisión por completo mientras validas el ajuste del producto al mercado. Ve nuestra guía completa sobre Integración de API de correo electrónico con OAuth para una inmersión profunda en patrones de producción.
Semanas de verificación.
Utilice Llave de Unipile y empezar ahora.
Probaste en el playground, ahora pasa a producción sin la espera de 6 meses de verificación de Google. Conecta cuentas de Gmail en 5 minutos con nuestras credenciales de desarrollador preverificadas.
De Google OAuth Playground a Producción: Omita la Espera de Verificación
La zona de pruebas confirmó que tu lógica de integración funciona. El siguiente paso es conectar cuentas de usuario reales en producción. Pero aquí está el problema: el proceso de verificación OAuth de Google para aplicaciones que solicitan ámbitos de Gmail sensibles o restringidos puede llevar 4 a 12 semanas, y requiere una auditoría de seguridad CASA Nivel 2 para alcances restringidos como gmail.modificar y gmail.enviar.
Unipile resuelve esto con credenciales de Google OAuth preverificadas. En lugar de esperar meses a que Google apruebe tu aplicación, usas clave del desarrollador con certificación CASA Nivel 2 de Unipile para conectar cuentas de Gmail de inmediato. Tus usuarios autorizan a través de la pantalla de consentimiento estándar de Google, tu aplicación lee y envía correos electrónicos a través de la API de Unipile y puedes cambiar a tus propias credenciales verificadas en cualquier momento cuando estés listo. Este es el mismo enfoque utilizado por los equipos que se basan en nuestras Integración de Google OAuth y nuestro más amplio Plataforma de API de correo electrónico.
Google OAuth Playground - Preguntas frecuentes
Respuestas a las preguntas más comunes sobre pruebas, tokens, ámbitos y paso a producción desde el entorno de pruebas.
En Google OAuth Playground es una herramienta gratuita basada en el navegador en developers.google.com/oauthplayground que permite a los desarrolladores probar flujos de autorización de OAuth 2.0 contra cualquier API de Google. Selecciona ámbitos, autoriza tu cuenta de Google, intercambia el código de autorización por tokens y realiza llamadas a la API en vivo, todo sin escribir código de backend. Mantenido por Google, admite todos los ámbitos de API de Google publicados.
Fichas de acceso expira después de 1 hora (3600 segundos). Tokens de actualización Las credenciales predeterminadas del playground de Google expiran después de 24 horas; esta es una limitación específica del playground. Si configuras el playground para usar tus propias credenciales de OAuth (ID de cliente y secreto de cliente de la Consola de Google Cloud), los tokens de actualización se comportan exactamente como los tokens de producción, sin que expiren a las 24 horas. También puedes hacer clic en "Actualizar token de acceso" en el Paso 2 en cualquier momento para obtener un nuevo token de acceso sin volver a autorizar.
No. El patio de recreo es un herramienta de prueba y depuración solamente. Está limitado a una cuenta de usuario (la tuya), los tokens caducan rápidamente con credenciales predeterminadas y no admite flujos de autorización multiusuario necesarios para aplicaciones de producción. Para producción, necesitas registrar tu propia aplicación OAuth, implementar el flujo de redirección de autorización en tu backend y, para ámbitos sensibles como gmail.modificar, completa el proceso de verificación de Google. Alternativamente, usa un servicio como Credenciales OAuth pre-verificadas de Unipile para enviar más rápido.
En la Google Cloud Console, crea una credencial de aplicación web de OAuth 2.0 y añade https://developers.google.com/oauthplayground como URI de redireccionamiento autorizada. Copia el ID del cliente y el secreto del cliente. En el playground, haz clic en icono de engranaje, habilita "Usar mis propias credenciales de OAuth" y pega tu ID de cliente y tu secreto de cliente. Haz clic en "Cerrar" y luego procede con la selección del alcance y la autorización del Paso 1 como de costumbre. Tus tokens ahora tendrán ciclos de vida equivalentes a los de producción.
La expiración de 24 horas se debe a que estás usando el credenciales compartidas predeterminadas del área de juegos (Cliente de OAuth propio de Google). Google limita intencionalmente estos tokens compartidos por motivos de seguridad. Así no funcionan los tokens de OAuth en producción. La solución es habilitar "Usar tus propias credenciales de OAuth" en la configuración de ajustes del playground y proporcionar tu propio ID de cliente y secreto de cliente. Con tus propias credenciales, los tokens de actualización son válidos hasta que el usuario revoque explícitamente el acceso o la aplicación esté inactiva durante 6 meses.
Sí, completamente. En la zona de juegos, Paso 1, expande "Gmail API v1" y selecciona cualquier alcance de Gmail (gmail.lectura, gmail.modificar, gmail.enviar, etc.). Después de la autorización, en el Paso 3 introduzca la URL del punto final, como https://gmail.googleapis.com/gmail/v1/users/me/messages y haz clic en "Enviar la solicitud". Verás la respuesta en vivo desde tu bandeja de entrada de Gmail. Para una referencia completa de los ámbitos de Gmail y sus permisos, consulta nuestra Guía de ámbitos de la API de Gmail.
La consola de desarrolladores admite todos los ámbitos de API de Google publicados. La lista integrada incluye Gmail API, Google Calendar, Google Drive, Google Sheets, Google Docs, Google Slides, Google Admin SDK, Google People API, Google Tasks, YouTube y muchos otros. También puede probar cualquier ámbito personalizado introduciendo la URL completa del ámbito manualmente en el campo "Introduzca sus propios ámbitos". Se pueden combinar varios ámbitos de diferentes API en una única solicitud de autorización.
Este error solo aparece cuando utilizas tus propias credenciales OAuth. Ve a Consola de Google Cloud, abre la configuración de tu cliente OAuth y agrega https://developers.google.com/oauthplayground como una URI de redireccionamiento autorizada. Guarda, espera unos minutos para que los cambios se propaguen, y luego vuelve a intentarlo. Si el error persiste, también intenta agregar la versión con una barra final. Para más correcciones de errores OAuth, consulta nuestro Guía de errores de Google OAuth.
Sí, el Google OAuth Playground es totalmente gratis. No se requiere ninguna cuenta para usar la interfaz del playground en sí, solo navega a developers.google.com/oauthplayground y accede con cualquier cuenta de Google. Las llamadas a la API que realices a través de la zona de juegos cuentan para la cuota de tu proyecto de Google Cloud (que tiene un nivel gratuito generoso para la mayoría de las API), pero la herramienta de zona de juegos en sí no tiene coste. Para una alternativa totalmente administrada, consulta API de Gmail lista para producción de Unipile.
Para aplicaciones SaaS que conectan cuentas de Gmail o Google Calendar para múltiples usuarios finales, Unipile proporciona una API OAuth lista para producción con credenciales de Google preverificadas (Certificada CASA Nivel 2, SOC 2, compatible con GDPR). En lugar del proceso de verificación de Google de 4 a 12 semanas para ámbitos restringidos, puede conectar cuentas de Gmail de usuarios de inmediato. También puede lee la documentación de Google OAuth de Unipile para ver las llamadas exactas a la API. Cambia a tus propias credenciales verificadas en cualquier momento sin interrupción.
¿Sigues teniendo preguntas sobre Google OAuth o el playground?
ES 
EN 
FR 
DE 
IT 
BR 
NL 
PL 
TR