with google auth android ios google-chrome single-sign-on google-oauth2

android - auth - Comportamiento de los navegadores de aplicaciones móviles con sesiones de Google y el Selector de cuentas



https accounts google com o oauth2 v2 auth (1)

Problema: Intentar crear SSO entre aplicaciones móviles. y el navegador.

Que tenemos:

Tenemos una aplicación móvil iónica. con "Iniciar sesión con Google" utilizando la autenticación OAuth 2.0. Tenemos varias aplicaciones internas que funcionan en OAuth2 y SAML, por lo tanto, tenemos SSO habilitado para GSuite para que todas las aplicaciones funcionen a la perfección con un solo inicio de sesión y contraseña. Ahora cuando pulsamos el botón "Iniciar sesión con Google",

  1. Se abre en la página de inicio de sesión de SSO en una aplicación de navegador. Tenemos SSO habilitado, por lo tanto, hemos configurado login_hint, que nos ayuda directamente a llevarnos a la página de inicio de sesión de SSO.

  2. El usuario ingresa el correo electrónico y la contraseña, y se redirige a redirect_uri después de la autenticación exitosa con el parámetro OAuth 2 code.

  3. Redirect_uri se realiza de manera que cuando se activa la url, se redirige nuevamente a nuestra aplicación de Android nuevamente con el parámetro OAuth 2 y luego extraemos access_token y useremail de los puntos finales de token y userinfo.

  4. Basándose en la autorización, el panel muestra los enlaces a nuestras aplicaciones internas. que funciona con la autenticación SAML 2.0 o OAuth2 de Google.

Lo que es esperado:

Cuando el usuario accede a cualquiera de los enlaces SAML / OAuth 2 desde la aplicación móvil. Panel de control, abrimos ese enlace en la aplicación del navegador. y debería iniciar sesión automáticamente en esa aplicación. y llévanos a la página de destino, ya que ya tenemos las sesiones de Google establecidas en el paso #a.

Cosas que se desvían de las expectativas:

  • Cuando intentamos acceder a las aplicaciones SAML / OAuth, aparece el selector de cuenta cuando hay un perfil configurado en el navegador Chrome que enumera todas las cuentas sincronizadas en el dispositivo pero no el usuario que ha iniciado sesión con #b. Debe mostrar esa cuenta o iniciar sesión directamente y mostrar la página de destino. No sucede cuando no tenemos un conjunto de perfiles de cromo.
  • Las sesiones en todos los navegadores se eliminan automáticamente cuando seguimos y, por lo tanto, vuelve a solicitar las credenciales.
    • cerrar la pestaña del navegador (a veces).
    • borra el navegador de la bandeja de aplicaciones recientes (la mayoría de las veces)
    • reiniciar el dispositivo (siempre)

¿Quería entender cómo y cuándo se crean y eliminan las sesiones automáticamente en Google Chrome en los teléfonos móviles?

¿Hay algún lugar donde mantener la sesión intacta? ¿Hay alguna forma de pasar por alto el selector de cuentas que muestra las cuentas sincronizadas con el teléfono?

Actualizar

Capaz de descubrir observaciones extrañas: mantuvimos el SSO desactivado para que la pantalla de inicio de sesión de Google aparezca en la imagen. Con esto todo funciona bien. Las sesiones no se eliminan incluso si reinicia el navegador o el teléfono independientemente de Android o iOS.

Así que el problema está en el SSO que hemos diseñado. No se puede averiguar qué se va a configurar en SAML XML que publicamos en la URL de ACS de Google.

1. ¿Quería entender cómo y cuándo se crean y eliminan las sesiones automáticamente en Google Chrome en los teléfonos móviles?

Creo que Google Chrome actúa en los teléfonos móviles de la misma manera que lo hace en las computadoras, por lo que las sesiones se crean y eliminan utilizando el almacenamiento de sesión HTML5 , la configuration usuario y las policies dispositivo:

Hay dos tipos de almacenamiento web hasta ahora, y estos son localStorage y sessionStorage. La principal diferencia es que el localStorage persiste en diferentes pestañas o ventanas, e incluso si localStorage el navegador, de acuerdo con la política de seguridad del dominio y las opciones del usuario sobre el límite de la cuota.

Además, es importante saber cómo Chrome guarda y sincroniza las contraseñas :

La forma en que Chrome guarda y sincroniza las contraseñas (en computadoras y dispositivos Android) depende de si desea almacenarlas y usarlas en todos los dispositivos. Cuando se sincronizan, las contraseñas se pueden utilizar en Chrome en todos sus dispositivos y en algunas aplicaciones en su dispositivo Android.

Sus contraseñas se guardan en su cuenta de Google si se cumple alguna de las siguientes condiciones:

  • Has iniciado sesión en Chrome y estás sincronizando contraseñas.
  • Estás utilizando Smart Lock para contraseñas en Android

De lo contrario, sus contraseñas solo se almacenan en Chrome en su computadora o dispositivo Android.

La forma en que Chrome guarda y sincroniza las contraseñas (en dispositivos iPhone y iPad) depende de si desea almacenarlas y usarlas en todos los dispositivos.

Sus contraseñas se guardan en su cuenta de Google si ha iniciado sesión en Chrome y está sincronizando las contraseñas.

De lo contrario, sus contraseñas solo se almacenan en Chrome en su iPhone o iPad.

2. ¿Hay alguna manera de mantener la sesión intacta?

No tengo habilidades ni interés en el desarrollo de iOs o HTML5, pero probé algo similar para Android y un dominio heredado de Google Apps cuando Google lanzó Smart Lock for Passwords en Android :

Guarde y recupere las credenciales mediante programación y firme automáticamente a los usuarios en todos los dispositivos y sitios web de Chrome.

Nota: se requiere SSL en su servidor para habilitar el inicio de sesión automático en aplicaciones y sitios web

La API de Smart Lock para contraseñas y cuentas conectadas facilita el almacenamiento y la recuperación de credenciales para su aplicación y el sitio asociado

Puede manejar múltiples credenciales guardadas y eliminar manualmente las credenciales almacenadas

Cuando se requiere la entrada del usuario para seleccionar una credencial, el método getStatusCode () devuelve RESOLUTION_REQUIRED. En este caso, llame al método startResolutionForResult () del objeto de estado para solicitar al usuario que elija una cuenta. Luego, recupere las credenciales elegidas por el usuario del método onActivityResult () de la actividad pasando Credential.EXTRA_KEY al método getParcelableExtra ().

Y Iniciar sesión utilizando los tokens de ID disponibles cuando la ID de usuario de un objeto Credential coincida con la ID de usuario de una cuenta de Google que haya iniciado sesión en el dispositivo.

Cómo implementarlo y escenarios útiles para test y check en las respuestas de SO relacionadas.

3. ¿Hay alguna manera de pasar por alto el selector de cuentas que muestra las cuentas sincronizadas con el teléfono?

Use Google Sign-In con aplicaciones de TI

Incluya en la lista blanca la aplicación para que los usuarios no vean una pantalla de confirmación cuando inicien sesión. Este paso, combinado con los siguientes pasos ( punto 4: pase el dominio Google for Work de la cuenta al servidor de autenticación, por lo que solo las cuentas en ese dominio son que se muestra durante el inicio de sesión ), garantiza que los usuarios de su aplicación de TI puedan iniciar sesión automáticamente. Para incluir en la lista blanca su aplicación:

  • Ingrese el ID de cliente de OAuth que registró para la aplicación. Una ID de cliente normalmente es una cadena de letras y números seguidos de .apps.googleusercontent.com.
  • En el campo Ámbitos de la API, escriba la siguiente cadena: https://www.googleapis.com/auth/plus.me,https://www.googleapis.com/auth/userinfo.email
  • Si su aplicación necesita solicitar ámbitos adicionales para acceder a las API de Google, especifíquelas aquí.
  • Haga clic en Autorizar. La lista blanca entrará en vigencia en unos 30 minutos.

Nota: la lista blanca no funcionará si la aplicación inicia el flujo de OAuth / Open ID Connect e incluye los parámetros fuera de línea o indicador . Estos parámetros generalmente no son necesarios para las aplicaciones de TI.

Forzar / omitir el selector de cuenta de Google en las URL de autorización de OAuth2

El siguiente parámetro es compatible con las URL de autorización de OAuth2:

Actualmente puede tener valores '' none '', '' select_account '' y '' consent ''.

ninguno : hará que Google no muestre ninguna IU y, por lo tanto, fallará si el usuario necesita iniciar sesión, o seleccionar una cuenta en caso de inicio de sesión múltiple o dar su consentimiento si es la primera aprobación. Puede ejecutarse en un i-frame invisible para obtener un token de usuarios previamente autorizados antes de que decida, por ejemplo, representar un botón de autorización.

consentimiento : forzará la visualización de la página de aprobación incluso si el usuario ha autorizado previamente su aplicación. Puede ser útil en algunos casos de esquina, por ejemplo, si perdió el refresh_token para el usuario, ya que Google solo emite refresh_tokens en la acción de consentimiento explícito.

select_account : hará que se muestre el selector de cuenta, incluso si hay un único usuario registrado, tal como lo pidió.

select_account se puede combinar con el consentimiento , como en: prompt=select_account+consent

utilizando la autorización a través de la biblioteca cliente JS

No está obteniendo la pantalla de selección multiusuario debido al siguiente parámetro: authuser = 0 Esto selecciona automáticamente la primera cuenta con la que ha iniciado sesión (authuser = 1 elegiría la segunda, etc.).

4. Actualización: con SSO desactivado, todo funciona bien ... las sesiones no se eliminan ...

SSO federado basado en SAML

Aquí se explica cómo configurar el inicio de sesión único (SSO) a través de SAML para la aplicación Slack® .

Con el lenguaje de marcado de aserción de seguridad (SAML), sus usuarios pueden usar sus credenciales de Google Cloud para iniciar sesión en las aplicaciones de nube empresarial.

Como administrador, tiene que configurar algunas cosas para hacer que funcione, incluyendo:

  • Configure la aplicación seleccionada como un proveedor de servicios SAML (SP).
  • Configure G Suite como un proveedor de identidad SAML (IdP).
  • Introduzca los detalles del proveedor de servicios específicos de la aplicación en la consola de administración de Google.
  • Active el inicio de sesión único (SSO) para la aplicación.
  • Verifique que el SSO esté funcionando.

Configure las aplicaciones en la nube preintegradas o su propia aplicación SAML

Inicia sesión . Haga clic en Aplicaciones> Aplicaciones SAML. Seleccione Agregar un servicio / aplicación a su dominio y configuración:

Active SSO en su nueva aplicación SAML :

Inicie sesión en su consola de administración . Vaya a Aplicaciones> Aplicaciones SAML .

Seleccione la aplicación. En la parte superior del cuadro gris, haga clic en Más configuraciones y elija:

  • Activado para que todos puedan activar el servicio para todos los usuarios (haga clic nuevamente para confirmar).
  • Desactivado para desactivar el servicio para todos los usuarios (vuelva a hacer clic para confirmar).
  • Activado para que algunas organizaciones cambien la configuración solo para algunos usuarios.

Use Google Sign-In con aplicaciones de TI

La siguiente es una lista de verificación de los pasos a seguir cuando se utiliza el inicio de sesión de Google con cuentas de trabajo para una aplicación de TI desarrollada a medida. Si está desarrollando una aplicación móvil, consulte también las mejores prácticas para dispositivos móviles .

Si su aplicación conoce el dominio de Google for Work de la cuenta, debe pasar ese dominio al servidor de autenticación para que solo se muestren las cuentas en ese dominio durante el inicio de sesión. En Android, esto se hace con el método del constructor setHostedDomain , y en iOS, esto se hace con la propiedad hostedDomain .

Esto también se hace utilizando el parámetro hd con el punto final REST y el parámetro hosting_dominio con la API de JavaScript.

5. Qué ... configurar en SAML XML que publicamos en la URL de ACS de Google.

Configuración de metadatos del proveedor para la integración de SAML

Los metadatos SAML se utilizan para compartir información de configuración entre el proveedor de identidad (IdP) y el proveedor de servicios (SP). Los metadatos para el IdP y el SP se definen en un archivo XML:

El archivo XML de metadatos de IdP contiene el certificado de IdP, el ID de entidad, la URL de redireccionamiento y la URL de publicación, por ejemplo, saml_idp_metadata.xml .

<?xml version="1.0" encoding="UTF-8"?> <md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" entityID="https://test.my.company.com" validUntil="2024-08-13T07:37:40.675Z"> <md:IDPSSODescriptor WantAuthnRequestsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"> <md:KeyDescriptor use="signing"> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate>encoded_certificate</ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </md:KeyDescriptor> <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://https://test.my.company.com/idp/endpoint/HttpPost"/> <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://test.my.company.com/idp/endpoint/HttpRedirect"/> </md:IDPSSODescriptor> </md:EntityDescriptor>

El archivo XML de metadatos del SP contiene el certificado del SP, el ID de la entidad y la URL del Servicio al consumidor de aserciones (URL de ACS), por ejemplo, saml_sp_metadata.xml .

<EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="http://client.mydomain.com:80/webconsole"> <SPSSODescriptor WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"> <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="http://client.mydomain.com:80/webconsole/samlAcsCallback.do" isDefault="true"/> <KeyDescriptor> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:X509Data> <ds:X509Certificate>encoded_certificate</ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </KeyDescriptor> <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:entity</NameIDFormat> </SPSSODescriptor> </EntityDescriptor>

Antes de utilizar SAML para iniciar sesión en la Consola Web, se deben cargar los metadatos del IdP y se deben generar los metadatos del SP. Una vez que se generan los metadatos del SP, se deben compartir con el IdP. Póngase en contacto con el IdP para obtener instrucciones sobre cómo compartir los metadatos del SP.

Cree un archivo XML de metadatos del proveedor de identidad (IdP) utilizando el protocolo SAML. Para obtener las especificaciones de metadatos de SAML, vaya al sitio web de Oasis , Metadatos para el lenguaje de marcado de aserción de seguridad (SAML) V2.0 de OASIS .

Crear un archivo de almacén de claves. Para obtener información sobre los archivos de almacén de claves, consulte Crear certificados para la integración de SAML .

Para obtener más información sobre la utilidad keytool, vaya al sitio web de documentación de Oracle , keytool - Key y Certificate Management Tool .

URL del proveedor de servicios SAML

Para configurar G Suite como proveedor de identidad SAML (IdP), debe ingresar las URL del proveedor de servicios SAML para cada una de las aplicaciones en la nube preconfiguradas individuales que planea configurar.

Enlaces para los valores de ID de entidad, URL de ACS y URL de inicio para cada una de las aplicaciones de nube preconfiguradas.

6. Solución de problemas de inicio de sesión único (SSO)

Este documento proporciona los pasos para resolver los mensajes de error comunes encontrados durante la integración o el uso del inicio de sesión único (SSO) basado en SAML con G Suite cuando Google es el proveedor de servicios (SP).