Introducción a los métodos de autenticación en Spotnana

Creado por Ashish Chaudhary, Modificado el Sab, 4 Oct a 10:38 A. M. por Ashish Chaudhary

Flujos de autenticación en Spotnana - Descripción general

TABLA DE CONTENIDOS

Spotnana ofrece diferentes métodos de autenticación para que los socios puedan integrar de forma segura nuestra plataforma. En este documento encontrará una visión general de los métodos de autenticación que actualmente admite Spotnana, junto con explicaciones detalladas sobre su funcionamiento. Los distintos flujos de autenticación aquí descritos muestran cómo Spotnana autentica y autoriza a los usuarios para que accedan a los recursos protegidos de su organización (es decir, los recursos que pertenecen a la empresa del usuario dentro de la plataforma Spotnana).


Componentes clave

Antes de comenzar, le recomendamos consultar esta lista con las definiciones de los componentes esenciales del sistema que se mencionan en esta documentación.

  • Interfaz de usuario de Spotnana(Interfaz de usuario de Spotnana) Hace referencia a la aplicación web de Spotnana (es decir, la herramienta de reservas en línea) o la aplicación móvil de Spotnana. Más concretamente, se refiere a la página de inicio de sesión, que es la que inicia el flujo de autenticación cuando el usuario accede o crea una nueva cuenta.
  • Servidor de Spotnana Se refiere al servidor backend de Spotnana utilizado para fines de autenticación (por ejemplo, autorizar el acceso de un usuario a un recurso y almacenar o procesar su información de forma segura).
  • Interfaz de usuario del socio (Interfaz de usuario del socio) Es la interfaz (o aplicación frontend) que utilizan los socios para acceder a la plataforma Spotnana. Por ejemplo, en la autenticación basada en iFrame, la plataforma Spotnana se integra dentro de la interfaz del socio, permitiendo que sus usuarios accedan a Spotnana directamente desde allí.
  • Servidor del socio Hace referencia a uno o varios servidores backend que utilizan nuestros socios para integrarse con Spotnana.
  • Spotnana IdP (Proveedor de Identidad de Spotnana) Es el servicio interno de Spotnana encargado de la gestión de identidades y la autorización de usuarios.
  • IdP del socio Proveedores de identidad externos (IdP) que utilizan los socios. Algunos ejemplos habituales son Google y Azure. 
  • OBT Herramienta de reservas en línea (OBT) de Spotnana, disponible en https://app.spotnana.com/ 
  • Token de sujeto En la autenticación basada en iFrame (o intercambio de tokens), el token de sujeto representa la identidad del usuario. Este token se utiliza para consultar su información y autorizar el acceso a la plataforma Spotnana.
  • Token de acceso Una credencial (OAuth) que utiliza una aplicación de socio para acceder a recursos protegidos en nombre de un usuario. Es una clave de autorización temporal que permite a las aplicaciones realizar solicitudes a la API sin exponer las credenciales del usuario.
  • Token de actualización Una credencial de larga duración que permite obtener nuevos tokens de acceso sin que el usuario deba autenticarse nuevamente. Normalmente se emite junto con el token de acceso durante la primera sesión de inicio de sesión.
  • Credenciales de cliente La información que se proporciona a los usuarios que se conectan directamente a las APIs de Spotnana (es decir, un clientId y un clientSecret).
  • PID (Identificador personal) Un identificador personal que se crea para el usuario. El PID permite recuperar la información del usuario desde el servidor de Spotnana.
  • orgId Identificador único que Spotnana asigna a la organización del usuario.
  • tmcId Identificador único que Spotnana asigna a una TMC (agencia de gestión de viajes).


Métodos de autenticación compatibles

A continuación encontrará los diferentes métodos de autenticación que admite Spotnana:


Autenticación con contraseña

Cuando se utiliza la autenticación con contraseña, la interfaz de Spotnana (es decir, la página de inicio de sesión o registro en la OBT) inicia y gestiona el proceso de autenticación con los servidores backend de Spotnana. Este método puede seguir dos caminos distintos, según si el usuario accede con un perfil ya existente o si está creando uno nuevo. A continuación se explica cada uno de estos flujos de autenticación, acompañados de diagramas de secuencia.


Usuario existente

El siguiente diagrama de secuencia y los pasos detallados explican cómo la interfaz de Spotnana interactúa con los servicios backend para autenticar a un usuario que ya tiene cuenta.

Fig: Diagrama de secuencia que explica la autenticación con contraseña para usuarios existentes.


PasoFlujo
Un usuario existente inicia sesión en la OBT o en la aplicación móvil de Spotnana utilizando su correo electrónico.
1
  • La interfaz de Spotnana envía una solicitud API al servidor de Spotnana para obtener la configuración de autenticación del usuario. En la solicitud se incluyen las credenciales de inicio de sesión del usuario como parámetros.
  • La respuesta contiene el tmcId, el orgIdy el authProviderTypedel usuario.
2
  • La interfaz de Spotnana envía una solicitud API al Spotnana IdP utilizando el clientId, correo electrónico y contraseña. El Spotnana IdP genera un nuevo token bearer y lo devuelve a la interfaz de Spotnana.
  • En este paso se autentica al usuario.
3
  • Una vez que el usuario ha sido autenticado en el paso 2, todas las solicitudes API posteriores deben incluir el token bearer, el orgIdy el tmcId en el encabezado de la solicitud.
  • El token bearer se valida en todas las solicitudes API entrantes y la respuesta se envía de vuelta a la interfaz de Spotnana.


Usuario nuevo

El siguiente diagrama de secuencia y los pasos detallados explican cómo la interfaz de Spotnana interactúa con los servicios backend para autenticar a un usuario nuevo (o a un usuario existente que desea restablecer su contraseña).


Fig: Diagrama de secuencia que explica la autenticación con contraseña para usuarios nuevos.


Paso
Flujo
Un usuario nuevo introduce su correo electrónico en la página de inicio de sesión de la OBT de Spotnana y hace clic en Siguiente.
1
  • La interfaz de Spotnana envía una solicitud API al servidor de Spotnana para obtener la configuración de autenticación del usuario. En la solicitud se incluyen las credenciales de inicio de sesión del usuario como parámetros.
  • La respuesta contiene el tmcId, el orgIdy el authProviderTypedel usuario.
1 a

El usuario introduce una nueva contraseña y hace clic en Siguiente.

2
  • La interfaz de Spotnana envía una solicitud API al Spotnana IdP para registrar al usuario junto con su clientId, correo electrónico y nueva contraseña.
  • Una vez registrados los datos, se envía una contraseña de un solo uso (OTP) al correo electrónico del usuario.
3
  • El usuario introduce el OTP en la interfaz de Spotnana y hace clic en Verificar.
  • La interfaz de Spotnana envía una solicitud al Spotnana IdP para verificar el OTP y generar un token bearer para el inicio de sesión.
  • El token bearer se genera y se devuelve a la interfaz de Spotnana, lo que indica que la autenticación fue exitosa y el usuario ya puede acceder a la plataforma Spotnana usando ese token.
4
  • Una vez que el usuario ha sido autenticado en el paso 3, todas las solicitudes API posteriores deben incluir el token bearer, el orgIdy el tmcId en el encabezado de la solicitud.
  • El token bearer se valida en todas las solicitudes API entrantes y la respuesta se envía de vuelta a la interfaz de Spotnana.


Autenticación basada en IdP

Spotnana permite autenticarse a través de IdPs como Google, Azure y otros IdPs personalizados que utilicen OpenID Connect o protocolos SAML. El siguiente diagrama de secuencia y los pasos detallados explican el flujo de autenticación basado en IdP.

Fig: Diagrama de secuencia que explica el flujo de autenticación basado en IdP.


PasoFlujo
Un usuario inicia sesión en la OBT o en la aplicación móvil de Spotnana utilizando su correo electrónico.
1
  • La interfaz de Spotnana envía una solicitud API al servidor de Spotnana para obtener la configuración de autenticación del usuario. En la solicitud se incluyen las credenciales de inicio de sesión del usuario como parámetros.
  • La respuesta contiene el tmcId, el orgIdy el authProviderTypedel usuario.
2

La interfaz de Spotnana redirige la solicitud al Spotnana IdP.

3

El Spotnana IdP redirige la solicitud al IdP del socio, lo que inicia la autenticación por parte del IdP externo.

Nota: En cada redirección, se devuelve un código de estado 302 para indicar que la solicitud ha sido redirigida a otra URL.
4

Se establece una conexión entre el Spotnana IdP y el IdP del socio, para asegurar que el usuario sea autenticado por el IdP externo.

Nota: Durante esta conexión, el Spotnana IdP envía el clientId y el clientSecret como datos codificados en formato URL a través de una llamada API al IdP del socio. Si los servidores IdP no pueden procesar ese formato, el servidor de Spotnana puede actuar como intermediario y transformar los datos al formato que el IdP del socio reconozca.
5

El IdP del socio autentica correctamente al usuario.

Nota: Después de este paso, el perfil del usuario aún debe pasar por la verificación del token bearer.
5 a

Tras la autenticación exitosa, la respuesta del IdP del socio se envía al Spotnana IdP.

5 b

El Spotnana IdP genera un código único para el perfil del usuario y lo envía a la interfaz de Spotnana.

6
  • La interfaz de Spotnana envía una solicitud API al Spotnana IdP utilizando el clientID y el código recibido en el paso 5(b).
  • El Spotnana IdP genera un nuevo token bearer y lo envía a la interfaz de Spotnana.
Nota: La creación exitosa del token bearer indica que el usuario ha sido autenticado y puede acceder a Spotnana.
7
  • Una vez que el usuario ha sido autenticado en el paso 6, todas las solicitudes API posteriores deben incluir el token bearer, el orgIdy el tmcId en el encabezado de la solicitud.
  • El token bearer se valida en todas las solicitudes API entrantes y la respuesta se envía de vuelta a la interfaz de Spotnana.


Autenticación basada en API

Los socios que utilizan las APIs de Spotnana para conectarse a la plataforma pueden usar nuestro endpoint de autenticación para generar un token bearer para sus usuarios. El siguiente diagrama de secuencia muestra el flujo de autenticación para cualquier socio que utilice este método.

Fig: Diagrama de secuencia que explica la autenticación basada en API.


PasoFlujo
1

El usuario de la API realiza una llamada POST a la API get-auth-token(clientId,clientSecret) en el servidor de Spotnana para generar y obtener un token bearer temporal.

A continuación se muestra un ejemplo de solicitud cUrl para utilizar al llamar al endpoint get-auth-token :

curl -i -X POST \
https://api.spotnana.com/get-auth-token \
-H 'Content-Type: application/json' \
-d '{
  "clientId": "sample-apiuser@tmcorg.com",
  "clientSecret": "<password>"
}'
Nota: Reemplace los valores de clientId y clientSecret por las credenciales que le haya proporcionado Spotnana. 
2
  • El servidor de Spotnana llama al método getToken(clientId,clientSecret) en el Spotnana IdP, que genera un bearerToken temporal y lo envía de vuelta al servidor de Spotnana.
  • El servidor de Spotnana envía este token bearer como respuesta en formato JSON al usuario de la API.


Una vez que el usuario de la API ha recibido el token bearer, todas las solicitudes posteriores a las APIs de Spotnana (por ejemplo, APIs de viajes) deben incluir el token bearer en el encabezado para la autorización. 

Nota: El endpoint get-auth-token(clientId, clientSecret) tiene un límite de 100 llamadas API cada 5 minutos.


Autenticación basada en iFrame

Una solución con iFrame o embebida consiste en que los socios integran la interfaz de Spotnana dentro de su propia interfaz, de modo que los usuarios acceden a Spotnana desde la interfaz del socio. En este escenario, la autenticación del usuario se gestiona mediante un intercambio de tokens entre los sistemas del socio y Spotnana.

Nota: En la autenticación basada en iFrame, al usuario que inicia sesión se le denominará caller. Esto permite contemplar casos en los que un usuario API/máquina inicia sesión y solicita un token de acceso para otro usuario. Dicho usuario API/máquina podría, por ejemplo, utilizar credenciales de administrador TMC para conectarse directamente con el servidor de Spotnana. Por eso, utilizaremos el término caller de forma general, ya sea para un usuario que accede a su propio perfil o para un usuario API/máquina que solicita un token de acceso en nombre de otro usuario.


El siguiente diagrama de secuencia muestra cómo se gestiona el flujo de autenticación mediante el intercambio de tokens entre Spotnana y los servidores del socio.

Fig: Diagrama de secuencia que explica la autenticación basada en iFrame mediante intercambio de tokens.


PasoFlujo
Un caller inicia sesión utilizando la interfaz del socio.
1La interfaz del socio muestra la interfaz de Spotnana a través de un iFrame.
2La interfaz de Spotnana envía una solicitud a la interfaz del socio mediante un post message para obtener los tokens. La solicitud se envía con type=TOKEN_EXCHANGE_REQUEST.
3

La interfaz del socio envía una solicitud API al servidor del socio para obtener el token OAuth, iniciando así los siguientes pasos del flujo de autenticación.

3 a

El servidor del socio llama al servidor de Spotnana usando las credenciales del usuario y el token de sujeto como parámetros. El servidor de Spotnana verifica si la solicitud proviene de un usuario API/máquina.

3 b
  • El servidor de Spotnana llama al servidor del socio para obtener el correo electrónico del sujeto (es decir, del caller).
  • El correo electrónico se recupera y se devuelve al servidor de Spotnana, que lo utiliza para identificar al usuario.
3 c
  • El servidor de Spotnana responde a la solicitud API del paso 1 enviando al servidor del socio el token de acceso y el token de actualización.
  • Estos datos se envían después a la interfaz del socio.
4

La interfaz del socio envía el token a la interfaz de Spotnana mediante un post message con type=TOKEN_EXCHANGE_RESPONSE.

5
  • La interfaz de Spotnana envía una solicitud API al servidor de Spotnana para generar y obtener un nuevo token bearer.
  • El servidor de Spotnana genera el token bearer y lo devuelve a la interfaz de Spotnana.
Nota: La creación exitosa del token bearer indica que el usuario ha sido autenticado y puede acceder a Spotnana.
6
  • Una vez que el usuario ha sido autenticado en el paso 3, todas las solicitudes API posteriores deben incluir el token bearer, el orgIdy el tmcId en el encabezado de la solicitud.
  • El token bearer se valida en todas las solicitudes API entrantes y la respuesta se envía de vuelta a la interfaz de Spotnana.


Autenticación basada en código de autorización

El siguiente diagrama de secuencia muestra cómo se gestiona el flujo de autenticación mediante un código de autorización.

Fig: Diagrama de secuencia que explica la autenticación basada en código de autorización.


PasoFlujo
1

La interfaz del socio llama al servidor del socio para obtener el código de autorización del caller que inicia sesión. El código se recupera y se envía de vuelta a la interfaz del socio.

2

La interfaz del socio envía una solicitud a la interfaz de Spotnana usando una URL de redirección personalizada que incluye el tmcId y el authCode como parámetros.

3

La interfaz de Spotnana realiza una llamada POST a la API del servidor de Spotnana usando el endpoint v2/auth/token/companies/<tmcId>(authCode) .

3 a
  • El servidor de Spotnana envía una solicitud al servidor del socio para obtener el pid del usuario utilizando el código de autorización.
  • El pid del usuario se recupera y se envía al servidor de Spotnana.
3 b

El servidor de Spotnana genera el token de acceso y el token de actualización y los envía a la interfaz de Spotnana.

4
  • La interfaz de Spotnana envía una solicitud al servidor de Spotnana usando el token de acceso y el token de actualización para generar y obtener el token bearer de acceso.
  • Se genera el token bearer y se envía a la interfaz de Spotnana.
Nota: La creación exitosa del token bearer indica que el usuario ha sido autenticado y puede acceder a Spotnana.
5
  • Una vez que el usuario ha sido autenticado en el paso 4, todas las solicitudes API posteriores deben incluir el token bearer, el orgIdy el tmcId en el encabezado de la solicitud.
  • El token bearer se valida en todas las solicitudes API entrantes y la respuesta se envía de vuelta a la interfaz de Spotnana.


Nota: Este flujo de autenticación no puede utilizarse en situaciones en las que un administrador TMC permita que varios usuarios inicien sesión con el mismo correo electrónico.


Autenticación máquina a máquina (M2M)

El método de autenticación M2M es ideal cuando el flujo de autenticación implica que la aplicación cliente acceda a una URL de callback de terceros para generar el accessToken del usuario. El siguiente diagrama de secuencia muestra el flujo de autenticación M2M.

Fig: Diagrama de secuencia que explica el flujo de autenticación M2M.


PasoFlujo
Las claves públicas de todas las aplicaciones utilizadas en la autenticación se sincronizan entre el servidor de Spotnana y el Spotnana IdP. Posteriormente, se utilizarán para verificar el token de acceso durante el flujo de autenticación.
1

El servidor del socio envía una solicitud API a /oauth2/token(clientId,clientSecret) en el Spotnana IdP para generar un token bearer. El nuevo token bearer se devuelve al servidor del socio.

2
  • El servidor del socio envía una solicitud API a una URL de callback de terceros para generar un token de acceso para el usuario.
  • Este token de acceso se crea y se envía al servidor de Spotnana.
3
  • El servidor de Spotnana valida la firma del token de acceso utilizando las claves públicas sincronizadas previamente. También valida el claim_id que verifica la identidad del socio.
  • El token de acceso se envía entonces al servidor del socio para autenticar al usuario.




¿Le ha sido útil este artículo?

¡Qué bien!

Gracias por sus comentarios

¡Sentimos mucho no haber sido de ayuda!

Gracias por sus comentarios

¡Háganos saber cómo podemos mejorar este artículo!

Seleccione al menos una de las razones
Se requiere la verificación del CAPTCHA.

Sus comentarios se han enviado

Agradecemos su esfuerzo e intentaremos corregir el artículo