Implementación del inicio de sesión único en aplicaciones nativas y vistas web integradas

Se aplica a: Círculo verde con un símbolo de marca de verificación blanca que indica que el siguiente contenido se aplica a los inquilinos externos. Inquilinos externos (más información)

Cuando la aplicación móvil incluye características basadas en web, como una página de actualización de perfil o un panel de recompensas, los usuarios esperan una experiencia de inicio de sesión único sin problemas. No deben encontrar un segundo aviso de inicio de sesión después de iniciar sesión a través de la aplicación nativa.

En este artículo se muestra cómo implementar el inicio de sesión único (SSO) entre una aplicación móvil nativa y un recurso web hospedado en una vista web incrustada (por ejemplo, WKWebView en iOS o WebView en Android). A diferencia de los exploradores del sistema, las vistas web insertadas permiten manipular las solicitudes de red antes de enviarlas. Esta funcionalidad permite a la aplicación insertar el estado de autenticación del usuario directamente en los encabezados de solicitud.

El flujo recomendado funciona de la siguiente manera:

  1. El usuario inicia sesión a través de la interfaz de usuario nativa de la aplicación móvil mediante el SDK de autenticación nativa o la API de autenticación nativa.
  2. Antes de cargar la vista web, la aplicación recupera un token de acceso válido desde el SDK o la API.
  3. La aplicación carga la vista web con una solicitud personalizada que incluye el token de acceso en el Authorization: Bearer <access_token> encabezado.
  4. El recurso web valida el token y concede acceso inmediatamente.

En el diagrama siguiente se muestra la interacción entre el recurso web, la aplicación móvil, el SDK y el servicio de identidad (ESTS):

Diagrama de secuencia que muestra el flujo de SSO en el que la aplicación móvil inicia sesión a través del SDK, recibe tokens y carga la vista web con el token de acceso en el encabezado Authorization.

Prerequisites

Iniciar sesión con autenticación nativa

Complete el flujo de inicio de sesión estándar mediante el SDK de autenticación nativa o la API de autenticación nativa. Cuando el inicio de sesión se realiza correctamente con el SDK, almacena en caché el token de acceso, el token de identificador y el token de actualización de forma segura. Si usa la API directamente, la aplicación es responsable de almacenar de forma segura los tokens que recibe.

Para obtener detalles sobre los pasos de implementación del inicio de sesión, consulte:

Recuperación del token de acceso

Cuando el usuario desencadena la acción para abrir la vista web, asegúrese de que la aplicación tiene un token de acceso válido y no expirado antes de cargar el recurso web.

Si usa el SDK de autenticación nativa, solicite un token de forma silenciosa. El SDK proporciona un getAccessToken() método que recupera un token válido de la memoria caché o lo actualiza de forma silenciosa. Para más información sobre cómo adquirir tokens de acceso con ámbitos específicos, consulte:

Si usa la API de autenticación nativa directamente, su aplicación recupera tokens a través del endpoint /oauth/v2.0/token de la API. Para más información, consulte Referencia de API de autenticación nativa.

Solicite el token con los ámbitos exactos requeridos por el recurso web. Para conocer los requisitos de ámbito, consulte Limitaciones y requisitos de configuración.

Carga de la vista web con autenticación

Hay dos métodos para pasar el estado de autenticación a la vista web. El enfoque recomendado usa encabezados de autorización. Está disponible una alternativa basada en cookies para escenarios heredados, pero no se recomienda.

Inserte el token de acceso directamente en el Authorization encabezado de la solicitud HTTP inicial que se usa para cargar la vista web. Este es el método más seguro y sólido.

Se prefiere este enfoque porque:

  • No tiene estado: no se basa en cookies persistentes en el lado cliente.
  • Aísla el token: limita estrictamente el token a este flujo de solicitud específico.
  • Evita vectores de ataque basados en web: elimina los problemas de seguridad comunes asociados a las sesiones administradas por el explorador.

Para cargar la vista web con autenticación basada en encabezados:

  1. Construya la dirección URL del recurso web. Asegúrese de que usa HTTPS.
  2. Cree un objeto de solicitud de red personalizado.
  3. Agregue el encabezado Authorization: Bearer <access_token> a la solicitud.
  4. Cargue la solicitud en el componente de vista web (por ejemplo, WKWebView en iOS o WebView en Android).

Opción B: Usar cookies (solo como respaldo)

Si el recurso web de destino no puede controlar la autenticación basada en encabezados (por ejemplo, determinadas aplicaciones heredadas de página única), puede insertar el token como una cookie. Por lo general, se desaconseja este enfoque debido a los riesgos de seguridad.

La inserción de cookies en una vista web confía el estado de autenticación a un mecanismo administrado por el explorador. Esto convierte la sesión en "ambiente" (asociada automáticamente a las solicitudes), lo que expone la aplicación a clases estándar de ataques web.

  • XSS (scripting de sitios cruzados): la sesión puede ser secuestrada si el contenido web está comprometido.
  • CSRF (falsificación de solicitudes entre sitios): hay un riesgo de solicitudes autenticadas no deseadas.
  • Fijación de sesión: un atacante podría tomar el control del estado de la sesión.
  • Cumplimiento: este enfoque entra en conflicto con los procedimientos recomendados de seguridad (por ejemplo, MASTG-KNOW-0018) con respecto a la conservación del estado confidencial en los archivos jar de cookies de vista web.

Warning

El enfoque basado en cookies se aprueba condicionalmente y, por lo general, se desaconseja. Úselo solo cuando el recurso web de destino no pueda admitir la autenticación basada en encabezados.

Si usa el enfoque basado en cookies, se aplican estos requisitos:

  • Use cookies de sesión emitidas por el servidor siempre que sea posible.
  • Evite colocar directamente tokens de acceso sin procesar en las cookies.
  • Establezca cookies con los atributos HttpOnly, Secure y los adecuados SameSite.
  • Aplique una protección CSRF estricta en el lado servidor.

Validar y conservar el token en el back-end

Cuando la solicitud llega al recurso web, el back-end procesa el token para establecer la sesión.

Validar el token

El servidor web intercepta las solicitudes entrantes y comprueba la firma y las notificaciones del token. Para los back-end de ASP.NET Core, use Microsoft.Identity.Web (MISE) para controlar la validación automáticamente.

Asegúrese de que la afirmación de audiencia (aud) del token coincide con el identificador de la API web y la afirmación del emisor (iss) coincide con la autoridad esperada.

Conservar la sesión

La vista web no conserva encabezados personalizados en eventos de navegación posteriores (por ejemplo, cuando el usuario selecciona un vínculo). Para mantener el estado autenticado después de la solicitud inicial, el servidor emite una cookie de sesión estándar (Set-Cookie) tras la validación correcta del token de portador inicial.

Configure la cookie de sesión con los atributos siguientes:

  • HttpOnly
  • Secure
  • Una directiva adecuada SameSite

Limitaciones y requisitos de configuración

Para asegurarse de que el recurso web acepta el token emitido a la aplicación móvil, tenga en cuenta las siguientes configuraciones:

  • Identidad de cliente compartida: la aplicación móvil y la aplicación web deben compartir el mismo identificador de cliente (id. de aplicación). Si tienen identificadores diferentes, el backend rechaza el token de la aplicación móvil debido a una incompatibilidad de audiencia.
  • Alineación del ámbito: la aplicación móvil solicita el token de acceso con los ámbitos exactos requeridos por el recurso web (por ejemplo, Profile.Read, Orders.Write).

Note

Esta solución está adaptada específicamente para el escenario de vista web. Se planea una solución más genérica que amplía las funcionalidades de SSO a exploradores del sistema y otros escenarios complejos para una versión futura.

Contenido relacionado

  • Last updated on