OAuth 2.0 para aplicaciones web del cliente

Este documento explica cómo implementar la autorización OAuth 2.0 para acceder Las APIs de Google desde una aplicación web de JavaScript OAuth 2.0 permite que los usuarios comparten datos específicos con una aplicación y conservan sus nombres de usuario, contraseñas y otras privada de la información. Por ejemplo, una aplicación puede usar OAuth 2.0 para obtener permiso de que los usuarios almacenen archivos en sus unidades de Google Drive.

Este flujo de OAuth 2.0 se denomina flujo de concesión implícito. Se diseñó para aplicaciones que acceden a las APIs solo cuando el usuario está presente en la aplicación. Estos las aplicaciones no pueden almacenar información confidencial.

En este flujo, tu app abre una URL de Google que usa parámetros de consulta para identificarla y el tipo de acceso a la API que requiere la app. Puedes abrir la URL en el navegador actual. o una ventana emergente. El usuario puede autenticarse con Google y otorgar los permisos solicitados. Luego, Google redirecciona al usuario de vuelta a tu app. El redireccionamiento incluye un token de acceso, el cual que tu app verifica y, luego, usa para realizar solicitudes a la API.

Biblioteca cliente de las APIs de Google y Google Identity Services

Si usas la biblioteca cliente de las APIs de Google para JavaScript Para realizar llamadas autorizadas a Google, debes usar Biblioteca de JavaScript de Google Identity Services para controlar el flujo de OAuth 2.0. Consulta a Google de servicios de identidad modelo de token, que es según el flujo de otorgamiento implícito 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 el API Console

Para habilitar una API en tu proyecto, haz lo siguiente:

  1. Open the API Library en Google API Console
  2. If prompted, select a project, or create a new one.
  3. El elemento API Library enumera todas las APIs disponibles, agrupadas por producto familia y popularidad. Si la API que quieres habilitar no está en la lista, usa la búsqueda para la encontrarás o haz clic en Ver todo en la familia de productos a la que pertenece.
  4. Selecciona la API que deseas habilitar y, luego, haz clic en el botón Habilitar.
  5. If prompted, enable billing.
  6. If prompted, read and accept the API's Terms of Service.

Crea credenciales de autorización

Cualquier aplicación que utilice OAuth 2.0 para acceder a las APIs de Google debe tener credenciales de autorización que identifican la aplicación en el servidor OAuth 2.0 de Google. Los siguientes pasos explican cómo crear credenciales para tu proyecto. Así, tus aplicaciones pueden usar las credenciales para acceder a las APIs que hayas habilitado para ese proyecto.

  1. Go to the Credentials page.
  2. Haz clic en Crear credenciales > ID de cliente de OAuth.
  3. Selecciona el tipo de aplicación Aplicación web.
  4. Completa el formulario. Aplicaciones que usan JavaScript para realizar solicitudes autorizadas a la API de Google debes especificar los orígenes de JavaScript autorizados. Los orígenes identifican los dominios desde el cual tu aplicación puede enviar solicitudes al servidor de OAuth 2.0. Estos orígenes deben cumplir 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 que les permite a los usuarios controlar el nivel de acceso que otorgan a tu aplicación. Por lo tanto, hay puede ser una relación inversa entre el número de alcances 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 que identifiques los alcances. a las que tu app necesitará permiso para acceder.

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

Obtén tokens de acceso de OAuth 2.0

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

Paso 1: Redirecciona al servidor OAuth 2.0 de Google

Si quieres solicitar permiso para acceder a los datos de un usuario, redirecciónalo a OAuth 2.0 de Google servidor.

Extremos de OAuth 2.0

Genera una URL para solicitar acceso desde el extremo de OAuth 2.0 de Google en https://accounts.google.com/o/oauth2/v2/auth Se puede acceder a este extremo 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 sitios web aplicaciones del servidor:

Parámetros
client_id Obligatorio

El ID de cliente de tu aplicación. Puedes encontrar este valor en API Console Credentials page

redirect_uri Obligatorio

Determina a dónde redirecciona el servidor de la API una vez que el usuario completa la de autorización. El valor debe coincidir exactamente con uno de los URI de redireccionamiento autorizados para el cliente de OAuth 2.0, que configuraste en la configuración API Console Credentials pageSi este valor no coincide con una URI de redireccionamiento autorizado para el client_id proporcionado, obtendrás un redirect_uri_mismatch error.

Ten en cuenta que el esquema http o https, las mayúsculas y minúsculas y la barra final (“/”) deben coincidir.

response_type Obligatorio

Las aplicaciones JavaScript deben establecer el valor del parámetro en token. Esta valor indica al servidor de autorización de Google que devuelva el token de acceso como un par name=value en el identificador de fragmento del URI (#) al que Se redirecciona al usuario después de completar el proceso de autorización.

scope Obligatorio

R delimitado por espacios una lista de alcances que identifican los recursos a los que tu aplicación podría acceder en el nombre del usuario. Estos valores informan 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 mismo tiempo que permiten a los usuarios controlar el nivel de acceso que le otorgan a su y mantener la integridad de su aplicación. Por lo tanto, existe una relación inversa entre el número de alcances solicitados. y la probabilidad de obtener el consentimiento del usuario.

Recomendamos que tu aplicación solicite acceso a los permisos de autorización en contexto siempre que sea posible. Solicitando acceso a los datos del usuario en contexto mediante la autorización incremental, ayudarás a los usuarios a comprender por qué tu aplicación necesita el acceso que solicita.

state Recomendado

Especifica cualquier valor de cadena que tu aplicación use para mantener el estado entre tus la 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 los redirect_uri después de que el usuario consienta o rechace la solicitud una solicitud de acceso.

Puedes usar este parámetro para varios fines, como dirigir al usuario a la el recurso correcto en tu aplicación, enviar nonces y mitigar las solicitudes entre sitios falsificación. Como tu redirect_uri se puede adivinar, usando un state valor, puedes tener más seguridad de que una conexión entrante es el resultado de una de autenticación de la organizació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 además de garantizar que la solicitud y la respuesta se originen en el mismo navegador brindando protección contra ataques como solicitud entre sitios falsificación. Consulta la OpenID Connect documentación de ejemplo para crear y confirmar un token state

include_granted_scopes Opcional

Permite que las aplicaciones usen autorización incremental para solicitar acceso a permisos de permisos en contexto. Si estableces el valor de este parámetro en true y el una solicitud de autorización, el nuevo token de acceso también abarcará los permisos en las que el usuario otorgó acceso a la aplicación con anterioridad. Consulta la autorización incremental para ver ejemplos.

login_hint Opcional

Si la 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 para simplificar el flujo de acceso, ya sea completando previamente el campo de correo electrónico en el formulario de acceso o 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.

prompt Opcional

Una lista de mensajes para el usuario delimitados por espacios y que distinguen mayúsculas de minúsculas. Si no especificas este parámetro, se le solicitará al usuario solo la primera vez que tu proyecto solicita acceso. Consulta Solicitar volver a dar el consentimiento para obtener más información.

Los valores posibles son:

none No muestres ninguna pantalla de autenticación ni de consentimiento. No se debe especificar con otros valores.
consent Solicita el consentimiento del usuario.
select_account Solicítale al usuario que seleccione una cuenta.

Ejemplo de redireccionamiento al servidor de autorización de Google

A continuación, se muestra una URL de ejemplo con saltos de línea y espacios para facilitar la lectura.

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A//www.googleapis.com/auth/drive.metadata.readonly&
 include_granted_scopes=true&
 response_type=token&
 state=state_parameter_passthrough_value&
 redirect_uri=https%3A//oauth2.example.com/code&
 client_id=client_id

Después de crear la URL de la solicitud, redirecciona al usuario a ella.

Código de muestra de JavaScript

El siguiente fragmento 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. Ya que este módulo de OAuth El extremo 2.0 no admite el uso compartido de recursos entre dominios (CORS), el fragmento crea un 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/drive.metadata.readonly',
                '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 otorgará a tu aplicación el acceso solicitado. En este Google muestra una ventana de consentimiento con el nombre de tu aplicación y la API de Google. servicios 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. El el usuario puede dar su consentimiento para otorgar acceso a uno o más alcances solicitados por tu aplicación o rechazar la solicitud.

Tu aplicación no necesita hacer nada en esta etapa mientras espera la respuesta del Servidor OAuth 2.0 de Google que indica si se otorgó algún 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 para el usuario. en lugar de los flujos esperados de autenticación y autorización. Códigos de error comunes y sugeridos del dispositivo se enumeran a continuación.

admin_policy_enforced

La Cuenta de Google no puede autorizar uno o más alcances 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é aplicaciones de terceros las apps internas 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 permisos restringidos hasta que se otorgue acceso explícitamente a tu ID de cliente de OAuth.

disallowed_useragent

El extremo de autorización se muestra dentro de un usuario-agente incorporado que Google no admite Políticas de OAuth 2.0

Android

Los desarrolladores de Android pueden encontrar este mensaje de error al abrir solicitudes de autorización en android.webkit.WebView En su lugar, los desarrolladores deberían usar bibliotecas de Android, como Acceso con Google para Android o de OpenID Foundation AppAuth para Android:

Los desarrolladores web pueden encontrar este error cuando una app para Android abre un vínculo web general en una usuario-agente incorporado y un usuario navega hasta el 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 de la un sistema operativo completo, que incluye Android App Links o la app de navegador predeterminada. El Pestañas personalizadas de Android biblioteca también es una opción admitida.

iOS

Los desarrolladores de iOS y macOS pueden encontrar este error cuando abren solicitudes de autorización en WKWebView En su lugar, los desarrolladores deberían usar bibliotecas de iOS, como Acceso con Google para iOS o de OpenID Foundation AppAuth para iOS:

Los desarrolladores web pueden encontrar 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 de la un sistema operativo completo, que incluye Vínculos universales o la app de navegador predeterminada. El SFSafariViewController biblioteca también es una opción admitida.

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 un específico Organización de Google Cloud. Para obtener más información sobre esta opción de configuración, consulta la Tipo de usuario del artículo de ayuda Configura tu pantalla de consentimiento de OAuth.

invalid_client

El origen desde el que se realizó la solicitud no está autorizado para este cliente. Consulta origin_mismatch

invalid_grant

Al usar la autorización incremental, es posible que el token haya vencido. o se invalidó. Vuelve a autenticar al usuario y pídele su consentimiento para obtener tokens nuevos. Si continúas para ver este error, asegúrate de que tu aplicación se configuró correctamente y de que usando los tokens y parámetros correctos en tu solicitud. De lo contrario, es posible que la cuenta de usuario se borró o inhabilitó.

origin_mismatch

Es posible que el esquema, el dominio o el puerto del JavaScript que originó la solicitud de autorización no puedan hacer coincidir un URI de origen autorizado de JavaScript registrado para el ID de cliente de OAuth. Revisión autorizada Orígenes de JavaScript en Google API Console Credentials page

redirect_uri_mismatch

El redirect_uri pasado en la solicitud de autorización no coincide con un Es el URI de redireccionamiento para el ID de cliente de OAuth. Revisa los URI de redireccionamiento autorizados en la Google API Console Credentials page

Es posible que el esquema, el dominio o el puerto del JavaScript que originó la solicitud de autorización no puedan hacer coincidir un URI de origen autorizado de JavaScript registrado para el ID de cliente de OAuth. Revisión orígenes autorizados de JavaScript en la Google API Console Credentials page

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

invalid_request

Se produjo un error con la solicitud que hiciste. Esto puede 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 tu OAuth integración usa un método de integración recomendado

Paso 3: Controla la respuesta del servidor de OAuth 2.0

Extremos de OAuth 2.0

El servidor de OAuth 2.0 envía una respuesta al redirect_uri especificado en tu una solicitud de token de acceso.

Si el usuario aprueba la solicitud, la respuesta contendrá un token de acceso. Si el usuario no aprueba la solicitud, la respuesta contiene un mensaje de error. El token de acceso el mensaje de error en el fragmento hash del URI de redireccionamiento, 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 del fragmento también contiene el parámetro token_type, que siempre está establecido en Bearer y el parámetro expires_in, que especifica la la vida útil del token, en segundos. Si se especificó el parámetro state de la solicitud de 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 de 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 de tu unidad de Google Drive:

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A//www.googleapis.com/auth/drive.metadata.readonly&
 include_granted_scopes=true&
 response_type=token&
 state=state_parameter_passthrough_value&
 redirect_uri=https%3A//oauth2.example.com/code&
 client_id=client_id

Después de completar el flujo de OAuth 2.0, se te redireccionará a http://localhost/oauth2callback Esa URL mostrará un 404 NOT FOUND, a menos que tu máquina local entregue un archivo en con esa dirección. En el siguiente paso, se proporcionan más detalles sobre la información que se devuelve en el Es el URI que se usa cuando se redirecciona al usuario de vuelta a tu aplicación.

Llama a las APIs de Google

Extremos de OAuth 2.0

Luego de que la aplicación obtenga un token de acceso, puedes usarlo para realizar llamadas a un servicio API en nombre de un proveedor de servicios de usuario si se otorgaron los permisos de acceso que requiere la API. Para ello, incluye el token de acceso en una solicitud a la API mediante una consulta access_token o un valor de encabezado HTTP Bearer Authorization. Cuando sea posible, se prefiere el encabezado HTTP, ya que las cadenas de consulta tienden a ser visibles en los registros del servidor. En la mayoría puedes usar una biblioteca cliente para configurar las llamadas a las APIs de Google (por ejemplo, cuando llamar a la API de Drive Files).

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

Ejemplos de solicitudes GET de HTTP

Un llamado a la drive.files extremo (la API de Drive Files) con el HTTP Authorization: Bearer el encabezado podría verse de la siguiente manera. Ten en cuenta que debes especificar tu propio token de acceso:

GET /drive/v2/files HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

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

GET https://www.googleapis.com/drive/v2/files?access_token=access_token

Ejemplos de curl

Puedes probar estos comandos con la aplicación de línea de comandos de curl. Este es un ejemplo que usa la opción de encabezado HTTP (preferida):

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files

Como alternativa, la opción de parámetro de cadena de consulta:

curl https://www.googleapis.com/drive/v2/files?access_token=access_token

Código de muestra de JavaScript

El siguiente fragmento de código demuestra cómo usar CORS (uso compartido de recursos entre dominios) para enviar un 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 estás usando la biblioteca cliente, el Compatibilidad con CORS de la documentación de esa biblioteca te resultará útil para comprender mejor estas solicitudes.

En este fragmento de código, la variable access_token representa el token que tienes que se obtienen para hacer solicitudes a la API en nombre del usuario autorizado. La fase completa ejemplo muestra cómo almacenar ese token en el almacenamiento local del navegador y recuperarlo cuando realizas una solicitud a la API.

var xhr = new XMLHttpRequest();
xhr.open('GET',
    'https://www.googleapis.com/drive/v3/about?fields=user&' +
    'access_token=' + params['access_token']);
xhr.onreadystatechange = function (e) {
  console.log(xhr.response);
};
xhr.send(null);

Ejemplo completo

Extremos de OAuth 2.0

Esta muestra de código muestra cómo completar el flujo de OAuth 2.0 en JavaScript sin usar el Biblioteca cliente de las APIs de Google para JavaScript. El código es para una página HTML que muestra un botón para prueba una solicitud a la API. Si haces clic en el botón, el código verifica si la página almacenó una 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, se inicia el flujo de OAuth 2.0.

Para el flujo de OAuth 2.0, la página sigue estos pasos:

  1. Dirige al usuario al servidor OAuth 2.0 de Google, que solicita acceso a la API de Permiso de https://www.googleapis.com/auth/drive.metadata.readonly.
  2. Después de otorgar (o denegar) el 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 del fragmento.
  3. La página utiliza el token de acceso para realizar la solicitud de API de muestra.

    La solicitud a la API llama al método about.get de la API de Drive para recuperar información sobre la cuenta de Google Drive del usuario autorizado.

  4. Si la solicitud se ejecuta correctamente, la respuesta de la API se registra en la depuración del navegador. de Cloud.

Puedes revocar el acceso a la app mediante la Permisos para las Cuenta de Google. La aplicación aparecerá como OAuth 2.0 Demo for Google API Docs.

Para ejecutar este código de manera local, debes establecer valores de YOUR_CLIENT_ID y YOUR_REDIRECT_URI que corresponden credenciales de autorización. La variable YOUR_REDIRECT_URI se debe establecer en la misma URL en la que se entrega la página. El valor debe coincidir exactamente con uno de los URI de redireccionamiento autorizados para el cliente de OAuth 2.0, que configuraste en el API Console Credentials pageSi este valor no coincide con un URI autorizado, obtendrás un redirect_uri_mismatch . Tu proyecto también debe tener habilitó 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/drive/v3/about?fields=user&' +
          '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/drive.metadata.readonly',
                  '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 origen de JavaScript

Google aplica las siguientes reglas de validación a los orígenes de JavaScript para ayudarte desarrolladores a mantener sus aplicaciones seguras. Los orígenes de JavaScript deben cumplir con estas reglas. Consulta la sección 3 del RFC 3986 para obtener del dominio, el host y el esquema, como se detalla a continuación.

Reglas de validación
Esquema

Los orígenes de JavaScript deben usar el esquema HTTPS, no el HTTP simple. URI de host local (incluidos los URI de direcciones IP del host local) están exentos de esta regla.

Host

Los hosts no pueden ser direcciones IP sin procesar. Las direcciones IP de host local están exentas de esta regla.

Dominio
  • TLD del host (Dominios de nivel superior) debe pertenecer a la lista pública de sufijos.
  • Los dominios de host no pueden ser “googleusercontent.com”.
  • Los orígenes de JavaScript no pueden contener dominios de acortamiento de URL (p.ej., goo.gl) a menos que la aplicación sea propietaria del dominio.
  • Información del usuario

    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 de acceso.

    Consulta

    Los orígenes de JavaScript no pueden contener el componente de consulta.

    Fragmento

    Los orígenes de JavaScript no pueden contener el componente del fragmento.

    Caracteres Los orígenes de JavaScript no pueden contener ciertos caracteres, entre los que se incluyen los siguientes:
    • Caracteres comodín ('*')
    • Caracteres ASCII no imprimibles
    • Codificaciones porcentuales no válidas (cualquier codificación porcentual que no siga la codificación de URL forma de un signo de porcentaje seguido de dos dígitos hexadecimales)
    • Caracteres nulos (un carácter NULL codificado, p.ej., %00, %C0%80)

    Autorización incremental

    En el protocolo OAuth 2.0, tu app solicita autorización para acceder a los recursos, los cuales se identificados por permisos. Solicitar autorización se considera una práctica recomendada de la experiencia del usuario. los recursos en el momento en que los necesites. Para habilitar esta práctica, el servidor de autorización de Google admite la autorización incremental. Esta función te permite solicitar permisos a medida que los necesites si el usuario otorga permiso para el nuevo alcance, devuelve un código de autorización por un token que contiene todos los permisos que el usuario le otorgó al proyecto.

    Por ejemplo, una aplicación que les permite a las personas probar pistas musicales y crear mixes podría necesitar muy pocas en el momento del acceso, tal vez nada más que el nombre de la persona que accede. Sin embargo, guardar un mix completo requeriría acceso a su unidad de Google Drive. La mayoría de la gente lo encontraría. natural si solo se les pidiera acceso a Google Drive en el momento en que la aplicación lo necesitaban.

    En este caso, durante el acceso, la app podría solicitar el openid y profile de permisos para realizar un acceso básico y, luego, solicitar el https://www.googleapis.com/auth/drive.file en el momento de la primera solicitud para guardar un mix.

    Las siguientes reglas se aplican 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 permisos incluidos en el nueva autorización combinada.
    • Cuando usa el token de actualización para la autorización combinada a fin de obtener un token de acceso, el el token de acceso representa la autorización combinada y puede usarse para cualquiera de los Valores scope incluidos en la respuesta.
    • La autorización combinada incluye todos los alcances que el usuario otorgó al proyecto de API, incluso si se solicitaron subsidios a diferentes clientes. Por ejemplo, si un usuario al que se le otorga acceso un alcance con un cliente de escritorio de una aplicación y, luego, se otorga otro alcance al mismo aplicación mediante un cliente móvil, la autorización combinada incluiría ambos alcances.
    • Si revoca un token que representa una autorización combinada, podrá acceder a todo ese token se revocan simultáneamente los permisos de la autorización en nombre del usuario asociado.

    En las siguientes muestras de código, se indica cómo agregar permisos a un token de acceso existente. Este enfoque permite tu app para evitar tener que administrar múltiples tokens de acceso.

    Extremos de OAuth 2.0

    Para agregar permisos a un token de acceso existente, incluye include_granted_scopes. en tu solicitud al servidor OAuth 2.0 de Google.

    En el siguiente fragmento de código, se muestra cómo hacerlo. El fragmento supone que almacenaste los permisos para los cuales tu token de acceso es válido en el almacenamiento local del navegador. (El El código de ejemplo completo almacena una lista de permisos para los cuales el token de acceso es válido estableciendo la propiedad oauth2-test-params.scope en la carpeta local del navegador storage.)

    El fragmento compara los permisos para los cuales el token de acceso es válido con el alcance que deseas usar para una consulta en particular. Si el token de acceso no abarca ese permiso, se inicia el flujo de OAuth 2.0. Aquí, la función oauth2SignIn es la misma que la que se proporcionó en paso 2 (y se proporciona más adelante en la fase completa ejemplo).

    var SCOPE = 'https://www.googleapis.com/auth/drive.metadata.readonly';
    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.
    }

    Revoca un token

    En algunos casos, es posible que el usuario desee revocar el acceso otorgado a una aplicación. Un usuario puede revocar el acceso en Configuración de la cuenta. Consulta la Quitar Acceso al sitio o la aplicación de la sección de Sitios de terceros y apps 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 anula la suscripción, quita aplicación o los recursos de API necesarios para una aplicación han cambiado considerablemente. En otras palabras, parte del proceso de eliminación pueden incluir una solicitud a la API para garantizar que los permisos previos otorgadas a la aplicación.

    Extremos de OAuth 2.0

    Para revocar un token de manera programática, la aplicación realiza una solicitud a https://oauth2.googleapis.com/revoke e 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 de acceso o 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 es 200 Para las condiciones de error, se muestra el 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 usar el Biblioteca cliente de las APIs de Google para JavaScript. Desde el extremo de OAuth 2.0 de Google para revocar Los tokens no admiten el uso compartido de recursos entre dominios (CORS), el código crea un formulario y lo envía. el formulario en el extremo, en lugar de usar el método XMLHttpRequest() para publicar el para cada 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();
    }

    Cómo implementar la Protección integral de la cuenta

    Un paso adicional que debes seguir para proteger las contraseñas de cuentas está implementando Protección con el Servicio de protección integral de la cuenta de Google Este servicio te permite suscribirse a las notificaciones de eventos de seguridad, que proporcionan información a su aplicación sobre cambios importantes en la cuenta de usuario. Luego, puedes usar la información para tomar medidas según cómo decides responder a los eventos.

    Estos son algunos ejemplos de los tipos de eventos que el Servicio de Protección integral de la cuenta 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 Cómo proteger las cuentas de usuario con la página Protección integral de la cuenta para obtener más información sobre cómo implementar la Protección integral de la cuenta y consultar la lista completa de eventos disponibles.