SSO mobile 3 opciones
18
SSO mobile 3 simples opciones @EguiMariano
-
Upload
mariano-german-egui -
Category
Technology
-
view
95 -
download
2
Transcript of SSO mobile 3 opciones
SSO mobile
3 simples opciones
@EguiMariano
About me...Mariano Germán Egui
Trabajo como desarrollador webMe gustan las buenas prácticasMe preocupa la seguridad de la aplicaciónParticipó de meetups y conferencias relacionadas a desarrollo e InfraestructuraSoy 100% amateur, programo en muchos lenguajes y me mande hacer el elefante de PHP
Twitter: @EguiMariano
@EguiMariano
ObjetivoLograr abrir una aplicación, autenticarse y desde esta abrir otra sin necesidad de volver a introducir usuario y contraseña; Manteniendo los estándares de OAuth2.
@EguiMariano
Nuestras opciones:
- Compartir los datos de autenticación.
- Usando deep linking.- Abriendo directamente la otra
aplicación con un codigo autorizado.
@EguiMariano
Compartiendo los datos de autenticación.
@EguiMariano
Tanto la App1 como App2 almacenan los datos de autenticación en el mismo lugar o de forma compartida. De esta manera se logra que todas las Apps instaladas en el mobile mantengan la sesión, pero en el caso de querer salir cerrará la sesión de todas a la vez.
Es realmente práctico pero inseguro❖ Experiencia de usuario:
➢ Buena;
La aplicación no requiere negociar token.
❖ Al intentar salir de una aplicación:➢ Sale de todas las aplicacione a la vez.
❖ Seguridad del usuario:
➢ Vulnerable;
Al compartir la información de access_token
y refresh_token otras aplicaciones pueden
tener acceso.
❖ Seguridad al salir de una aplicación:➢ Sale de todas las aplicacione a la vez.
➢ No puede manejar las sesiones de las APPs
por separado.
OAuth2: Mantiene los estándares del RFC pero no distingue el cliente, ambas aplicaciones son las mismas para el servidor OAuth
@EguiMariano
Usando deep linking.@EguiMariano
La App1 y la App2 almacenan los datos de autenticación de forma privada. Al abrir la App2 se inicia el flujo deep linking solicitando acceso a App1 por URL con un codigo, su client_id y su redirect_uri. Una vez autorizado este obtiene un ‘código’ válido donde utilizara el flujo de grant_type:authorization_code para poder acceder.
Familiar y brinda opciones al usuario❖ Experiencia de usuario:
➢ Regular;
El usuario debe seleccionar si desea abrir la
URL con el navegador o la aplicación
instalada.
➢ Debe cerrar la sesión en cada una de las
aplicaciones del mobile.
❖ Al intentar salir de una aplicación:➢ Sale sin cerrar sesion de otra.
❖ Seguridad del usuario:
➢ Alta;
Cada aplicacion maneja su almacenamiento
de datos, y su propias credenciales de
cliente.
❖ Seguridad al salir de una aplicación:➢ Solo cierra la session de sí misma.
OAuth2: Mantiene los estándares del RFC.
@EguiMariano
Abriendo directamente la otra aplicación con un codigo autorizado.
@EguiMariano
Si desde la App1 queremos abrir la App2 previamente negociamos un codigo válido para autorizacion. Por protocolos mobile lanzamos la App2 con el código como parámetro para que este obtenga su access_token por un request de tipo ‘grant_type:authorization_code’.
Es práctico, seguro y simple para el usuario❖ Experiencia de usuario:
➢ Buena;
La otra aplicación negocia el token sin
interacción del usuario.
➢ Debe cerrar la sesión en cada una de las
aplicaciones del mobile.
❖ Al intentar salir de una aplicación:➢ Sale sin cerrar sesion de otra.
❖ Seguridad del usuario:
➢ Alto;
Cada aplicacion maneja su almacenamiento
de datos, y su propias credenciales de
cliente.
❖ Seguridad al salir de una aplicación:➢ Solo cierra la session de sí misma.
OAuth2: Mantiene los estándares del RFC, sin confirmación del usuario.
@EguiMariano
¿Como funciona el grant type authorization_code?
@EguiMariano
El proceso de autorización por códigoEn principio se solicita la aceptación del usuario autenticado en el navegador/mobile a una url GET, al aceptarla se hace request POST con los parámetros:
1. response_type: code2. client_id3. redirect_uri4. code
Esto nos devuelve un nuevo código que usaremos para el authorization_code
@EguiMariano
Haciendo POST con el nuevo código y los siguientes parámetros
1. response_type: authorization_code2. client_id3. client_secret4. redirect_uri5. code
Obtengo el access_token y refresh_token, que usare de ahora en mas.
@EguiMariano
A mas bajo nivelEl parámetro ‘code’ se encodea desde el primer request como ID de referencia en la autorización, su valor no es fuerte, por lo que podemos ignorarlo o sacarle provecho para realizar validaciones internas.
El ‘request_uri’ se utiliza a nivel web para indicar a donde enviar el código y facilitar la redirección al usuario, pero a bajo nivel se utiliza como dato adicional para identificar y validar el cliente, por ese motivo es requerido en el grant type: authorization_code.
La validez del código de autorización es parametrizable, pero no debe durar mucho más que la transacción misma, ejemplo 1 minuto.
Una vez autorizada la nueva aplicación en el futuro deberá gestionar su ‘access_token’ con el ‘refresh_token’ y no con el ‘code’.
@EguiMariano
En el tercer caso de SSO en apps mobileDijimos que respetamos el RFC, pero no solicitamos la aprobación del usuario con el ‘response_type: code’; Esto es porque siendo aplicaciones de la misma familia podemos saltearnos la aceptación del usuario y gestionando el ‘code’ para OAuth Server desde nuestra sesión conociendo en la App1 el client_id y redirect_uri de la App2.
App1:
Realiza el request response_type: code para obtener un código autorizadoLuego abre la App2 con el code generadoApp2:Realiza el request grant_type: authorization_code para obtener el access_token
@EguiMariano
