Este documento presenta tres opciones para implementar un único inicio de sesión (SSO) entre aplicaciones móviles: 1) compartiendo los datos de autenticación, 2) usando enlaces profundos, 3) abriendo directamente la otra aplicación con un código autorizado. La tercera opción es la más práctica, segura y simple para el usuario.

1. SSO mobile
3 simples opciones
@EguiMariano

2. About me...
Mariano Germán Egui
Trabajo como desarrollador web
Me gustan las buenas prácticas
Me preocupa la seguridad de la aplicación
Participó de meetups y conferencias relacionadas a
desarrollo e Infraestructura
Soy 100% amateur, programo en muchos lenguajes y me
mande hacer el elefante de PHP
Twitter: @EguiMariano
egui.mariano@gmail.com
@EguiMariano

3. @EguiMariano

4. Objetivo
Lograr 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

5. Nuestras
opciones:
- Compartir los datos de
autenticación.
- Usando deep linking.
- Abriendo directamente la otra
aplicación con un codigo
autorizado.
@EguiMariano

6. 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.

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

8. 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.

9. 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

10. 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’.

11. 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

12. ¿Como funciona el
grant type
authorization_code?
@EguiMariano

13. El proceso de autorización por código
En 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: code
2. client_id
3. redirect_uri
4. code
Esto nos devuelve un nuevo código que usaremos para el authorization_code
@EguiMariano

14. Haciendo POST con el nuevo código y los siguientes parámetros
1. response_type: authorization_code
2. client_id
3. client_secret
4. redirect_uri
5. code
Obtengo el access_token y refresh_token, que usare de ahora en mas.
@EguiMariano

16. A mas bajo nivel
El 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

17. En el tercer caso de SSO en apps mobile
Dijimos 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 autorizado
Luego abre la App2 con el code generado
App2:
Realiza el request grant_type: authorization_code para obtener el access_token
@EguiMariano

18. ¿Preguntas?
@EguiMariano