Este documento explica cómo implementar la autorización OAuth 2.0 para acceder a la API de datos de YouTube desde una aplicación web JavaScript. OAuth 2.0 permite a los usuarios compartir datos específicos con una aplicación manteniendo privados 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.
Este flujo de OAuth 2.0 se denomina flujo de concesión implícita. Está diseñado para aplicaciones que acceden a las API solo mientras el usuario está presente en la aplicación. Estas aplicaciones no pueden almacenar información confidencial.
En este flujo, su aplicación abre una URL de Google que utiliza parámetros de consulta para identificar su aplicación y el tipo de acceso a la API que requiere la aplicación. Puede abrir la URL en la ventana actual del navegador o en una ventana emergente. El usuario puede autenticarse con Google y otorgar los permisos solicitados. Google redirige al usuario a tu aplicación. Esta redirección incluye un token de acceso que tu aplicación verifica y utiliza para realizar solicitudes a la API.
Biblioteca de clientes de API de Google y servicios de identidad de Google
Si usa la biblioteca cliente de API de Google para JavaScript para realizar llamadas autorizadas a Google, debe usar la biblioteca de JavaScript Servicios de identidad de Google para manejar el flujo de OAuth 2.0. Consulta el modelo de token de los Servicios de identidad de Google, que se basa en el flujo de concesión implícita de OAuth 2.0.
Requisitos previos
Habilita las API para tu proyecto.
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:
- Open the API Library en el Google API Console.
- If prompted, select a project, or create a new one.
- Utilice la página Biblioteca para encontrar y habilitar la API de datos de YouTube. Encuentre otras API que su aplicación utilizará y habilítelas también.
Crea credenciales de autorización
Todas las aplicaciones que usan OAuth 2.0 para acceder a las APIs de Google deben tener credenciales de autorización que identifiquen la aplicación en 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.
- Go to the Clients page.
- Haz clic en Crear cliente.
- Selecciona el tipo de aplicación Aplicación web.
- Completa el formulario. Las aplicaciones que usan JavaScript para realizar solicitudes de API de Google autorizadas deben especificar orígenes de JavaScript autorizados. Los orígenes identifican los dominios desde los cuales su aplicación puede enviar solicitudes al servidor OAuth 2.0. Estos orígenes deben cumplir con las reglas de validación de Google.
Identifica los permisos de acceso
Los permisos permiten que tu 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 permisos a los que tu app necesitará acceder.
La versión 3 de la API de YouTube Data usa los siguientes alcances:
| Alcance | Descripción |
|---|---|
https://www. |
Administrar tu cuenta de YouTube |
https://www. |
Ver una lista de los miembros actuales y activos de su canal, su nivel actual y el momento en que se hicieron miembros |
https://www. |
Vea, edite y borre de forma permanente sus videos, calificaciones, comentarios y subtítulos de YouTube |
https://www. |
Permite ver tu cuenta de YouTube. |
https://www. |
Permite administrar tus videos de YouTube. |
https://www. |
Ver y administrar sus elementos y el contenido asociado en YouTube |
https://www. |
Ver información privada de tu canal de YouTube que sea relevante durante el proceso de auditoría con un socio de YouTube |
El documento Permisos de la API de OAuth 2.0 contiene una lista completa de los permisos que puedes usar para acceder a las APIs de Google.
Cómo obtener tokens de acceso de OAuth 2.0
En los siguientes pasos, se muestra cómo interactúa tu aplicación con el servidor de OAuth 2.0 de Google para obtener el consentimiento de un usuario para realizar una solicitud a la API en su nombre. Tu aplicación debe tener ese consentimiento antes de poder ejecutar una solicitud de la API de Google que requiera autorización del usuario.
Paso 1: Redirigir al servidor OAuth 2.0 de Google
Para solicitar permiso para acceder a los datos de un usuario, redirija al usuario al servidor OAuth 2.0 de Google.
Puntos finales de OAuth 2.0
Genere una URL para solicitar acceso desde el punto final OAuth 2.0 de Google en https://accounts.google.com/o/oauth2/v2/auth. Se puede acceder a este punto final a través de HTTPS; se rechazan las conexiones HTTP simples.
El servidor de autorización de Google admite los siguientes parámetros de cadena de consulta para aplicaciones de servidor web:
| Parámetros | |||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
client_id |
Obligatorio
Es el ID de cliente de tu aplicación. Puedes encontrar este valor en Cloud Console Clients page. |
||||||||||||||||
redirect_uri |
Obligatorio
Determina a dónde redirecciona el servidor de la API al usuario después de que este completa el flujo de autorización. El valor debe coincidir exactamente con uno de los URIs de redireccionamiento autorizados para el cliente de OAuth 2.0 que configuraste en el Cloud Consoledel cliente Clients page. Si este valor no coincide con un URI de redireccionamiento autorizado para el Ten en cuenta que el esquema |
||||||||||||||||
response_type |
Obligatorio
Las aplicaciones de JavaScript deben establecer el valor del parámetro en |
||||||||||||||||
scope |
Obligatorio
Lista de alcances separados por espacios que identifican los recursos a los que tu aplicación podría acceder en nombre del usuario. Estos valores informan a la pantalla de consentimiento que Google muestra al usuario. Los permisos permiten que tu 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 alcances:
En el documento Permisos de la API de OAuth 2.0, se proporciona una lista completa de los permisos que puedes usar para acceder a las APIs de Google. Te recomendamos que tu aplicación solicite acceso a los permisos de autorización en contexto siempre que sea posible. Al solicitar acceso a los datos del usuario en contexto, mediante la autorización incremental, ayuda a los usuarios a comprender por qué su aplicación necesita el acceso que solicita. |
||||||||||||||||
state |
Recomendado
Especifica cualquier valor de cadena que tu aplicación use para mantener el estado entre tu solicitud de autorización y la respuesta del servidor de autorización.
El servidor devuelve el valor exacto que envías como un par 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 tu |
||||||||||||||||
include_granted_scopes |
Opcional
Permite que las aplicaciones usen la autorización incremental para solicitar acceso a alcances adicionales en contexto. Si estableces el valor de este parámetro en |
||||||||||||||||
enable_granular_consent |
Opcional
La configuración predeterminada es Cuando Google habilite los permisos detallados para una aplicación, este parámetro ya no tendrá ningún efecto. |
||||||||||||||||
login_hint |
Opcional
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 de |
||||||||||||||||
prompt |
Opcional
Es una lista de instrucciones delimitadas por espacios que distinguen mayúsculas de minúsculas para presentar al usuario. Si no especificas este parámetro, se le solicitará al usuario solo la primera vez que tu proyecto solicite acceso. Consulta Cómo solicitar un nuevo consentimiento para obtener más información. Los valores posibles son:
|
||||||||||||||||
Ejemplo de redireccionamiento al servidor de autorización de Google
La siguiente URL de ejemplo solicita acceso sin conexión (access_type=offline) a un alcance que permite ver la cuenta de YouTube del usuario. Utiliza la autorización incremental para garantizar que el nuevo token de acceso abarque todos los permisos a los que el usuario otorgó acceso a la aplicación anteriormente. La URL también establece valores para los parámetros obligatorios redirect_uri, response_type y client_id, así como para el parámetro state. La 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&
include_granted_scopes=true&
state=state_parameter_passthrough_value&
redirect_uri=http%3A%2F%2Flocalhost%2Foauth2callback&
response_type=token&
client_id=client_idDespués de crear la URL de la solicitud, redirecciona al usuario a ella.
Código de muestra de JavaScript
El siguiente fragmento de código de JavaScript muestra cómo iniciar el flujo de autorización en JavaScript sin usar la biblioteca cliente de las APIs de Google para JavaScript. Dado que este extremo de OAuth 2.0 no admite el uso compartido de recursos entre dominios (CORS), el fragmento crea un formulario que abre la solicitud a ese extremo.
/* * Create form to request access token from Google's OAuth 2.0 server. */ function oauthSignIn() { // Google's OAuth 2.0 endpoint for requesting an access token var oauth2Endpoint = 'https://accounts.google.com/o/oauth2/v2/auth'; // Create <form> element to submit parameters to OAuth 2.0 endpoint. var form = document.createElement('form'); form.setAttribute('method', 'GET'); // Send as a GET request. form.setAttribute('action', oauth2Endpoint); // Parameters to pass to OAuth 2.0 endpoint. var params = {'client_id': 'YOUR_CLIENT_ID', 'redirect_uri': 'YOUR_REDIRECT_URI', 'response_type': 'token', 'scope': 'https://www.googleapis.com/auth/youtube.force-ssl', 'include_granted_scopes': 'true', 'state': 'pass-through value'}; // Add form parameters as hidden input values. for (var p in params) { var input = document.createElement('input'); input.setAttribute('type', 'hidden'); input.setAttribute('name', p); input.setAttribute('value', params[p]); form.appendChild(input); } // Add form to page and submit it to open the OAuth 2.0 endpoint. document.body.appendChild(form); form.submit(); }
Paso 2: Google solicita el consentimiento del usuario
En este paso, el usuario decide si otorga a tu aplicación el acceso solicitado. En esta etapa, Google muestra una ventana de consentimiento que incluye 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, así como un resumen de los permisos de acceso que se otorgarán. Luego, el usuario puede dar su consentimiento para otorgar acceso a uno o más permisos solicitados por tu aplicación, o bien rechazar la solicitud.
Tu aplicación no necesita hacer nada en esta etapa, ya que espera la respuesta del servidor OAuth 2.0 de Google que indica si se otorgó acceso. Esa respuesta se explica en el siguiente paso.
Errores
Las solicitudes al extremo de autorización de OAuth 2.0 de Google pueden mostrar mensajes de error visibles para el usuario en lugar de los flujos de autenticación y autorización esperados. Estos son los códigos de error comunes y las resoluciones sugeridas:
admin_policy_enforced
La Cuenta de Google no puede autorizar uno o más de los permisos solicitados debido a las políticas de su administrador de Google Workspace. Consulta el artículo de ayuda para administradores 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.
disallowed_useragent
El extremo de autorización se muestra dentro de un agente de usuario incorporado que no permiten las políticas de OAuth 2.0 de Google.
Los desarrolladores de iOS y macOS pueden encontrar este error cuando abren 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.
Los desarrolladores web pueden encontrarse con este error cuando una app para iOS o macOS abre un vínculo web general en un agente de usuario 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 del navegador predeterminado. La biblioteca de SFSafariViewController también es una opción compatible.
org_internal
El ID de cliente de OAuth de 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 Configura tu pantalla de consentimiento de OAuth.
invalid_client
El origen desde el cual se realizó la solicitud no está autorizado para este cliente. Ver origin_mismatch.
deleted_client
Se borró el cliente de OAuth que se usa para realizar la solicitud. La eliminación puede ocurrir de forma manual o automática en el caso de los clientes no utilizados. Los clientes borrados se pueden restablecer en un plazo de 30 días después de la eliminación. Más información .
invalid_grant
Al utilizar la autorización incremental, es posible que el token haya expirado o se haya invalidado. Vuelve a autenticar al usuario y pídele su consentimiento para obtener tokens nuevos. Si sigues viendo este error, asegúrate de que tu aplicación se haya configurado correctamente y de que estés usando los tokens y parámetros correctos en tu solicitud. De lo contrario, es posible que se haya borrado o inhabilitado la cuenta de usuario.
origin_mismatch
Es posible que el esquema, el dominio o el puerto del JavaScript que origina la solicitud de autorización no coincidan con un URI de origen de JavaScript autorizado registrado para el ID de cliente OAuth. Revise los orígenes de JavaScript autorizados en Google Cloud Console Clients page.
redirect_uri_mismatch
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 URIs de redireccionamiento autorizados en Google Cloud Console
Clients page.
Es posible que el esquema, el dominio o el puerto del JavaScript que origina la solicitud de autorización no coincidan con un URI de origen de JavaScript autorizado registrado para el ID de cliente OAuth. Revise los orígenes de JavaScript autorizados en Google Cloud Console Clients page.
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.
invalid_request
Se produjo un error con la solicitud que realizaste. Esto podría deberse a varios motivos:
- La solicitud no tenía el formato correcto
- Faltaban parámetros obligatorios en la solicitud
- La solicitud usa un método de autorización que Google no admite. Verifica que tu integración de OAuth use un método de integración recomendado
Paso 3: Gestionar la respuesta del servidor OAuth 2.0
Puntos finales de OAuth 2.0
El servidor OAuth 2.0 envía una respuesta al redirect_uri especificado en su solicitud de token de acceso.
Si el usuario aprueba la solicitud, la respuesta contiene un token de acceso. Si el usuario no aprueba la solicitud, la respuesta contiene un mensaje de error. El token de acceso o el mensaje de error se devuelve en el fragmento hash del URI de redirección, como se muestra a continuación:
Una respuesta de token de acceso:
https://oauth2.example.com/callback#access_token=4/P7q7W91&token_type=Bearer&expires_in=3600
Además del parámetro
access_token, la cadena de fragmento también contiene el parámetrotoken_type, que siempre se establece enBearer, y el parámetroexpires_in, que especifica la vida útil del token, en segundos. Si se especificó el parámetrostateen la solicitud del token de acceso, su valor también se incluye en la respuesta.- Una respuesta de error:
https://oauth2.example.com/callback#error=access_denied
Ejemplo de respuesta del servidor OAuth 2.0
Para probar este flujo, haz clic en la siguiente URL de ejemplo, que solicita acceso de solo lectura para ver los metadatos de los archivos en tu Google Drive y acceso de solo lectura para ver los eventos de tu Calendario de Google:
https://accounts.google.com/o/oauth2/v2/auth? scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.readonly& include_granted_scopes=true& state=state_parameter_passthrough_value& redirect_uri=http%3A%2F%2Flocalhost%2Foauth2callback& response_type=token& client_id=client_id
Después de completar el flujo de OAuth 2.0, su navegador lo redireccionará a OAuth 2.0 Playground, una herramienta para probar flujos de OAuth. Verá que OAuth 2.0 Playground ha capturado automáticamente el código de autorización.
Paso 4: Verificar qué alcances otorgaron los usuarios
Cuando solicitas varios permisos (alcances), es posible que los usuarios no le otorguen a tu app acceso a todos ellos. Tu app debe verificar qué alcances se otorgaron realmente y controlar de forma adecuada las situaciones en las que se deniegan algunos permisos, por lo general, inhabilitando las funciones que dependen de esos alcances 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 Confiables 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 cambio, tu app recibirá todos los alcances solicitados o ninguno.
Para obtener información más detallada, consulta Cómo controlar permisos detallados.
Extremos de OAuth 2.0
Para verificar si el usuario otorgó acceso a tu aplicación a un alcance en particular, examina el campo scope en la respuesta del token de acceso. Son los permisos de acceso otorgados por el access_token, expresados como una lista de cadenas sensibles a mayúsculas y minúsculas delimitadas por espacios.
Por ejemplo, la siguiente respuesta de muestra del token de acceso indica que el usuario otorgó permiso a tu aplicación para ver, editar y borrar de forma permanente los videos, las calificaciones, los comentarios y los subtítulos de YouTube del usuario:
{ "access_token": "1/fFAGRNJru1FTz70BzhT3Zg", "expires_in": 3920, "token_type": "Bearer", "scope": "https://www.googleapis.com/auth/youtube.force-ssl", "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI" }
Llama a las APIs de Google
Extremos de OAuth 2.0
Después de que tu aplicación obtiene un token de acceso, puedes usarlo para llamar a una API de Google en nombre de una cuenta de usuario determinada si se otorgaron los permisos de acceso requeridos por la API. Para ello, incluye el token de acceso en una solicitud a la API con un parámetro de consulta access_token o un valor Bearer del encabezado HTTP Authorization. Cuando sea posible, se recomienda usar 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 solo admite cuentas de servicio para los 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.
Ejemplos de HTTP GET
Una llamada al extremo
youtube.channels (la API de YouTube Data) 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
Ejemplos de curl
Puedes probar estos comandos con la aplicación de línea de comandos de 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, de forma alternativa, la opción del parámetro de cadena de consulta:
curl https://www.googleapis.com/youtube/v3/channels?access_token=access_token&part=snippet&mine=true
Código de muestra de JavaScript
En el siguiente fragmento de código, se muestra cómo usar CORS (uso compartido de recursos entre dominios) para enviar una solicitud a una API de Google. En este ejemplo, no se usa la biblioteca cliente de las APIs de Google para JavaScript. Sin embargo, incluso si no usas la biblioteca cliente, es probable que la guía de compatibilidad con CORS en la documentación de esa biblioteca te ayude a comprender mejor estas solicitudes.
En este fragmento de código, la variable access_token representa el token que obtuviste para realizar solicitudes a la API en nombre del usuario autorizado. El ejemplo completo muestra cómo almacenar ese token en el almacenamiento local del navegador y recuperarlo cuando se realiza una solicitud a la API.
var xhr = new XMLHttpRequest(); xhr.open('GET', 'https://www.googleapis.com/youtube/v3/channels?part=snippet&mine=true&' + 'access_token=' + params['access_token']); xhr.onreadystatechange = function (e) { console.log(xhr.response); }; xhr.send(null);
Ejemplo completo
Extremos de OAuth 2.0
En este ejemplo de código, se muestra cómo completar el flujo de OAuth 2.0 en JavaScript sin usar la biblioteca cliente de las APIs de Google para JavaScript. El código es para una página HTML que muestra un botón para probar una solicitud a la API. Si haces clic en el botón, el código verifica si la página almacenó un token de acceso a la API en el almacenamiento local de tu navegador. Si es así, ejecuta la solicitud a la API. De lo contrario, inicia el flujo de OAuth 2.0.
En el flujo de OAuth 2.0, la página sigue estos pasos:
- Dirige al usuario al servidor de OAuth 2.0 de Google, que solicita acceso al permiso
https://www.googleapis.com/auth/youtube.force-ssl. - Después de otorgar (o denegar) acceso a uno o más permisos solicitados, se redirecciona al usuario a la página original, que analiza el token de acceso de la cadena del identificador de fragmento.
- En la página, se verifica a qué permisos otorgó acceso el usuario a la aplicación.
Si el usuario otorgó acceso a los alcances solicitados, la página usa el token de acceso para realizar la solicitud a la API de muestra.
Esta solicitud a la API llama al método
channels.listde la API de YouTube Data para recuperar datos sobre el canal de YouTube del usuario autorizado.- Si la solicitud se ejecuta correctamente, la respuesta de la API se registra en la consola de depuración del navegador.
Puedes revocar el acceso a la app en la página Permisos de tu Cuenta de Google. La app aparece como el nombre de la aplicación proporcionado en la página de desarrollo de la marca dentro de la pantalla de consentimiento de OAuth durante la creación del ID de cliente.
Para ejecutar este código de forma local, debes establecer valores para las variables YOUR_CLIENT_ID y YOUR_REDIRECT_URI que correspondan a tus credenciales de autorización. La variable YOUR_REDIRECT_URI debe establecerse en la misma URL en la que se entrega la página. El valor debe coincidir exactamente con uno de los URIs de redireccionamiento autorizados para el cliente de OAuth 2.0, que configuraste en Cloud Console
Clients page. Si este valor no coincide con un URI autorizado, recibirás un error redirect_uri_mismatch. Tu proyecto también debe tener habilitada la API adecuada para esta solicitud.
<html><head></head><body>
<script>
var YOUR_CLIENT_ID = 'REPLACE_THIS_VALUE';
var YOUR_REDIRECT_URI = 'REPLACE_THIS_VALUE';
// Parse query string to see if page request is coming from OAuth 2.0 server.
var fragmentString = location.hash.substring(1);
var params = {};
var regex = /([^&=]+)=([^&]*)/g, m;
while (m = regex.exec(fragmentString)) {
params[decodeURIComponent(m[1])] = decodeURIComponent(m[2]);
}
if (Object.keys(params).length > 0 && params['state']) {
if (params['state'] == localStorage.getItem('state')) {
localStorage.setItem('oauth2-test-params', JSON.stringify(params) );
trySampleRequest();
} else {
console.log('State mismatch. Possible CSRF attack');
}
}
// Function to generate a random state value
function generateCryptoRandomState() {
const randomValues = new Uint32Array(2);
window.crypto.getRandomValues(randomValues);
// Encode as UTF-8
const utf8Encoder = new TextEncoder();
const utf8Array = utf8Encoder.encode(
String.fromCharCode.apply(null, randomValues)
);
// Base64 encode the UTF-8 data
return btoa(String.fromCharCode.apply(null, utf8Array))
.replace(/\+/g, '-')
.replace(/\//g, '_')
.replace(/=+$/, '');
}
// If there's an access token, try an API request.
// Otherwise, start OAuth 2.0 flow.
function trySampleRequest() {
var params = JSON.parse(localStorage.getItem('oauth2-test-params'));
if (params && params['access_token']) {
var xhr = new XMLHttpRequest();
xhr.open('GET',
'https://www.googleapis.com/youtube/v3/channels?part=snippet&mine=true&' +
'access_token=' + params['access_token']);
xhr.onreadystatechange = function (e) {
if (xhr.readyState === 4 && xhr.status === 200) {
console.log(xhr.response);
} else if (xhr.readyState === 4 && xhr.status === 401) {
// Token invalid, so prompt for user permission.
oauth2SignIn();
}
};
xhr.send(null);
} else {
oauth2SignIn();
}
}
/*
* Create form to request access token from Google's OAuth 2.0 server.
*/
function oauth2SignIn() {
// create random state value and store in local storage
var state = generateCryptoRandomState();
localStorage.setItem('state', state);
// Google's OAuth 2.0 endpoint for requesting an access token
var oauth2Endpoint = 'https://accounts.google.com/o/oauth2/v2/auth';
// Create element to open OAuth 2.0 endpoint in new window.
var form = document.createElement('form');
form.setAttribute('method', 'GET'); // Send as a GET request.
form.setAttribute('action', oauth2Endpoint);
// Parameters to pass to OAuth 2.0 endpoint.
var params = {'client_id': YOUR_CLIENT_ID,
'redirect_uri': YOUR_REDIRECT_URI,
'scope': 'https://www.googleapis.com/auth/youtube.force-ssl',
'state': state,
'include_granted_scopes': 'true',
'response_type': 'token'};
// Add form parameters as hidden input values.
for (var p in params) {
var input = document.createElement('input');
input.setAttribute('type', 'hidden');
input.setAttribute('name', p);
input.setAttribute('value', params[p]);
form.appendChild(input);
}
// Add form to page and submit it to open the OAuth 2.0 endpoint.
document.body.appendChild(form);
form.submit();
}
</script>
<button onclick="trySampleRequest();">Try sample request</button>
</body></html>Reglas de validación de orígenes de JavaScript
Google aplica las siguientes reglas de validación a los orígenes de JavaScript para ayudar a los desarrolladores a mantener sus aplicaciones seguras. Sus orígenes de JavaScript deben cumplir estas reglas. Consulte la sección 3 del RFC 3986 para obtener la definición de dominio, host y esquema, mencionados a continuación.
| Reglas de validación | |
|---|---|
| Esquema |
Los orígenes de JavaScript deben utilizar el esquema HTTPS, no HTTP simple. Los URI de host local (incluidos los URI de direcciones IP de host local) están exentos de esta regla. |
| Host |
Los hosts no pueden ser direcciones IP sin procesar. Las direcciones IP de localhost están exentas de esta regla. |
| Dominio |
“googleusercontent.com”.goo.gl) a menos que la aplicación sea propietaria del dominio. |
| Userinfo |
Los orígenes de JavaScript no pueden contener el subcomponente userinfo. |
| Ruta de acceso |
Los orígenes de JavaScript no pueden contener el componente de ruta. |
| Consulta |
Los orígenes de JavaScript no pueden contener el componente de consulta. |
| Fragmento |
Los orígenes de JavaScript no pueden contener el componente de fragmento. |
| Caracteres |
Los orígenes de JavaScript no pueden contener ciertos caracteres, incluidos:
|
Autorización incremental
En el protocolo de OAuth 2.0, tu app solicita autorización para acceder a recursos, que se identifican por permisos. Se considera una práctica recomendada para la experiencia del usuario solicitar autorización para los recursos en el momento en que los necesites. Para habilitar esa práctica, el servidor de autorización de Google admite la autorización incremental. Esta función te permite solicitar permisos cuando los necesites y, si el usuario otorga permiso para el nuevo alcance, devuelve un código de autorización que se puede intercambiar por un token que contenga todos los permisos que el usuario otorgó al proyecto.
Por ejemplo, supongamos que una app ayuda a los usuarios a identificar eventos locales interesantes. La app permite que los usuarios miren videos sobre los eventos, los califiquen y los agreguen a playlists. Los usuarios también pueden usar la app para agregar eventos a sus calendarios de Google.
En este caso, es posible que, en el momento del acceso, la app no necesite ni solicite acceso a ningún alcance. Sin embargo, si el usuario intentó calificar un video, agregarlo a una playlist o realizar otra acción de YouTube, la app podría solicitar acceso al alcance de https://www.googleapis.com/auth/youtube.force-ssl.
Del mismo modo, la app podría solicitar acceso al alcance de https://www.googleapis.com/auth/calendar si el usuario intentó agregar un evento de calendario.
Se aplican las siguientes reglas a un token de acceso obtenido de una autorización incremental:
- El token se puede usar para acceder a los recursos correspondientes a cualquiera de los alcances incluidos en la nueva autorización combinada.
- Cuando usas el token de actualización para la autorización combinada y obtener un token de acceso, este representa la autorización combinada y se puede usar para cualquiera de los valores de
scopeincluidos en la respuesta. - La autorización combinada incluye todos los permisos que el usuario otorgó al proyecto de API, incluso si los permisos se solicitaron desde diferentes clientes. Por ejemplo, si un usuario otorgó acceso a un permiso con el cliente de escritorio de una aplicación y, luego, otorgó otro permiso a la misma aplicación a través de un cliente móvil, la autorización combinada incluiría ambos permisos.
- Si revocas un token que representa una autorización combinada, se revoca simultáneamente el acceso a todos los alcances de esa autorización en nombre del usuario asociado.
Los ejemplos de código a continuación muestran cómo agregar ámbitos a un token de acceso existente. Este enfoque permite que su aplicación evite tener que administrar múltiples tokens de acceso.
Puntos finales de OAuth 2.0
En este ejemplo, la aplicación que realiza la llamada solicita acceso para recuperar los datos de YouTube Analytics del usuario, además de cualquier otro acceso que el usuario ya haya otorgado a la aplicación.
Para agregar ámbitos a un token de acceso existente, incluya el parámetro include_granted_scopes en su solicitud al servidor OAuth 2.0 de Google.
El siguiente fragmento de código demuestra cómo hacerlo. El fragmento asume que ha almacenado los ámbitos para los cuales su token de acceso es válido en el almacenamiento local del navegador. (El código del ejemplo completo almacena una lista de ámbitos para los cuales el token de acceso es válido al configurar la propiedad oauth2-test-params.scope en el almacenamiento local del navegador).
El fragmento compara los ámbitos para los cuales el token de acceso es válido con el ámbito que desea utilizar para una consulta particular. Si el token de acceso no cubre ese alcance, se inicia el flujo OAuth 2.0.
Aquí, la función oauth2SignIn es la misma que la que se proporcionó en el paso 2 (y que se proporciona más adelante en el ejemplo completo).
var SCOPE = 'https://www.googleapis.com/auth/youtube.force-ssl'; var params = JSON.parse(localStorage.getItem('oauth2-test-params')); var current_scope_granted = false; if (params.hasOwnProperty('scope')) { var scopes = params['scope'].split(' '); for (var s = 0; s < scopes.length; s++) { if (SCOPE == scopes[s]) { current_scope_granted = true; } } } if (!current_scope_granted) { oauth2SignIn(); // This function is defined elsewhere in this document. } else { // Since you already have access, you can proceed with the API request. }
Revocación de tokens
En algunos casos, es posible que un usuario desee revocar el acceso que le otorgó a una aplicación. Para revocar el acceso, el usuario debe visitar la configuración de la cuenta. Consulta la sección para quitar el acceso de sitios o apps del documento de asistencia Sitios y apps de terceros con acceso a tu cuenta para obtener más información.
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 la suscripción, quita una aplicación o los recursos de la API que requiere una app cambiaron significativamente. En otras palabras, parte del proceso de eliminación puede incluir una solicitud a la API para garantizar que se quiten los permisos que se otorgaron anteriormente a la aplicación.
Puntos finales de OAuth 2.0
Para revocar un token de forma programática, tu aplicación realiza una solicitud a https://oauth2.googleapis.com/revoke y, luego, 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 de acceso y tiene un token de actualización correspondiente, también se revocará el token de actualización.
Si la revocación se procesa correctamente, el código de estado HTTP de la respuesta será 200. En caso de error, se muestra un código de estado HTTP 400 junto con un código de error.
El siguiente fragmento de JavaScript muestra cómo revocar un token en JavaScript sin utilizar la biblioteca de cliente de API de Google para JavaScript. Dado que el punto final OAuth 2.0 de Google para revocar tokens no admite el uso compartido de recursos de origen cruzado (CORS), el código crea un formulario y lo envía al punto final en lugar de usar el método XMLHttpRequest() para publicar la solicitud.
function revokeAccess(accessToken) { // Google's OAuth 2.0 endpoint for revoking access tokens. var revokeTokenEndpoint = 'https://oauth2.googleapis.com/revoke'; // Create <form> element to use to POST data to the OAuth 2.0 endpoint. var form = document.createElement('form'); form.setAttribute('method', 'post'); form.setAttribute('action', revokeTokenEndpoint); // Add access token to the form so it is set as value of 'token' parameter. // This corresponds to the sample curl request, where the URL is: // https://oauth2.googleapis.com/revoke?token={token} var tokenField = document.createElement('input'); tokenField.setAttribute('type', 'hidden'); tokenField.setAttribute('name', 'token'); tokenField.setAttribute('value', accessToken); form.appendChild(tokenField); // Add form to page and submit it to actually revoke the token. document.body.appendChild(form); form.submit(); }
Implementa la Protección integral de la cuenta
Un paso adicional que debes seguir para proteger las cuentas de tus usuarios es implementar la Protección entre cuentas utilizando el servicio de Protección entre cuentas de Google. Este servicio te permite suscribirte a las notificaciones de eventos de seguridad, que proporcionan información a tu aplicación sobre los 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:
-
https://schemas.openid.net/secevent/risc/event-type/sessions-revoked -
https://schemas.openid.net/secevent/oauth/event-type/token-revoked -
https://schemas.openid.net/secevent/risc/event-type/account-disabled
Consulta la página Protección de 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.