Información general sobre el SSO de OpenID Connect

OpenID Connect (OIDC) es un protocolo de autenticación basado en OAuth 2.0 que han adoptado las principales empresas tecnológicas.

>> Más información sobre OIDC

SSO básico

Independientemente de las funciones que hayas seleccionado, los requisitos de configuración del SSO básico son los mismos. Para añadir implementaciones de fidelidad o tarjetas de crédito, se pedirá más información.

Requisitos de configuración

Para configurar correctamente el acceso SSO de OIDC a tu sitio web creado a partir de una plantilla, necesitaremos varios datos, como los siguientes:

• API (autorización, token, userProfile, JWKS)
• ID de cliente
• Secreto de cliente
• ResponseMode
• isNounceEnabled
• customerDetailsAPIKey (si está disponible)

Flujos de autorización

Autorizar punto final

El punto de conexión GET /authorize se utiliza para la autenticación y la autorización. Una vez que el usuario ha iniciado sesión, te devuelve una concesión de autorización o un código. Es una redirección del navegador que te lleva a introducir tus credenciales para autenticarte.

Parámetros de solicitud

Parámetros de respuesta

URL de ejemplo para la autorización

https://example.com/authorize?client_id={clientID}&response_type=code&state=d6b93799-404b-4205-9bb3-c579b1180428&scope=openid email profile&nounce=234567687867&redirect_uri=https://{ExpediaDomain}/sso/auth

URL de devolución de llamada de ejemplo

https://{ExpediaDomain}/sso/auth?code=12345678&state=d6b93799-404b-4205-9bb3-c579b1180428

Punto final de tokens

El punto final POST /token es una llamada a la API de backend que se utiliza para obtener un token de acceso y un token de identificación mediante la presentación de una concesión de autorización o un código de autorización.

Parámetros de solicitud

Encabezados de solicitud

Parámetros de respuesta

ID_token

ID_token es un token web JSON (JWT) que incluye fragmentos de información de autenticación llamados reclamaciones. Las soluciones de plantilla de Expedia utilizan las reclamaciones header, payload y signature com en la tabla siguiente.

Reclamaciones de encabezado

Reclamaciones de carga

Reclamaciones de firma

Validación de la firma: La firma se validará con la clave correspondiente (que se puede consultar en JWKS endpoint) para ese client_id y ese algoritmo.

Ejemplo de token CURL

curl --location 'https://example.com/token’ \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'Authorization: Basic {encoded ClientID:clientSecret}' \
--data-urlencode 'grant_type=authorization_code' \
--data-urlencode 'redirect_uri=https://{ExpediaDomain}/sso/auth’ \
--data-urlencode 'code={Authorization code after login as part of callback to Expedia /sso/auth endpoint}'

Ejemplo de respuesta con token

{
    "access_token": "eyJhbGciOi.JSUzI1NiIsImtpZCI6Ilk1MkFDVXd3QV9SUzI1NiIsInBp.LmF0bSI6ImlrY20ifQ",
    "id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6.IllEQnJQdlllYlRwa1laODZoaGk1MkFDVX.d3QV9SUzI1NiJ9",
    "token_type": "Bearer",
    "expires_in": 1799
}

Punto final de información del usuario

El punto final « GET /userinfo » es una llamada a la API de backend que devuelve las reclamaciones del usuario autenticado en función del token de acceso proporcionado. Devuelve los datos del perfil de usuario, que se usan para incluir el nombre del cliente en el encabezado de la cuenta de la web, lo que a su vez permite cargar la información sobre el nivel de fidelidad a través de la cuenta del programa.

Nota: Si no se incluyen los parámetros obligatorios en la respuesta, esto provocará problemas en la experiencia del cliente en la web. Por ejemplo, el nombre del cliente no aparecerá en la página de la plantilla, y faltará la información de la cuenta del programa necesaria para conectarse al proceso de inscripción en el programa de fidelización en Expedia's.

Encabezados de solicitud

Respuesta

Ejemplo de «userinfo» con CURL

curl --location 'https://example.com/userinfo' \
--header 'client_id: {clientId}' \
--header 'Authorization: Bearer {acess_token from token endpoint}'

Ejemplo de respuesta de «Userinfo»

{
  "membershipId": "12345678",
  "languageID": "en",
  "middleName": "MiddleName",
  "lastName": "LastName",
  "firstName": "FirstName",
  "email": "test@expediagroup.com",
  "programAccount": {
    "programId": "Gold",
    "loyaltyAccountBalance": {
      "value": "10000",
      "currency": "Points"
    }
  }
}

Añadir programa de fidelidad

Como parte de tu sitio web basado en una plantilla, puedes incluir la opción de que los clientes ganen puntos de fidelidad con sus compras de viajes. Si lo deseas, tu plantilla también puede permitir que los clientes utilicen sus puntos de fidelidad acumulados para comprar viajes.

>> Más información sobre los puntos de fidelidad

Se aplican los mismos requisitos de configuración que en la implementación estándar, así como muchos de los valores. Aquí solo se incluyen los que son diferentes.

Además del valor estándar « user information », la configuración del programa de fidelización incluirá los siguientes valores.

programAccount

Importe

Restringir tarjeta de pago

Podemos configurar tu página web para que los viajeros tengan que usar la tarjeta de crédito de tu organización para hacer la reserva. Es opcional, ya que todas las soluciones de plantilla pueden aceptar cualquier tarjeta de crédito o débito de las entidades principales y (en EE. UU.) PayPal.

Almacenamiento y seguridad de tarjetas de crédito

Si decides obligar a utilizar la tarjeta de crédito personalizada de tu organización en las compras, queremos que sea con seguridad. Así es como lo gestionamos.

• La información de la tarjeta se almacena en un formato de token que está vinculado al perfil del cliente en Expedia. Nunca se almacena sin cifrar.
• Ningún ser humano tiene acceso a los datos de tarjetas cifrados, y solo se descifran con las credenciales de IAM seguras.
• Cuando se precarga una tarjeta en la página de pago, solo se muestra la descripción de la tarjeta, pero no el número.
• El cliente debe introducir el CVV de la tarjeta para completar la reserva con la tarjeta almacenada.

Requisitos de configuración

Además de los requisitos de configuración de la implementación estándar, cuando introduzcas tu tarjeta de crédito tendremos que añadir lo siguiente:

• Un punto de conexión para utilizar con el parámetro AuthnRequest.
• Tu clave pública para la verificación de firma.

Utilizaremos la clave privada de Expedia para firmar la carga AuthnRequest y nuestra clave pública para que valides la firma.

Detalles de carga

Junto con los atributos descritos en la implementación estándar, cuando un cliente inicia sesión en tu sitio web, el SSO de tarjeta de crédito inicia el envío de dos parámetros de transacción al punto de conexión seguro de SSO de Expedia:

• API de información del usuario: carga de respuesta codificada y firmada con afirmaciones firmadas y cifradas.
• RelayState: un enlace profundo a la URL de la página de destino.

>> Más información sobre la API de información de usuario

La carga también incluirá los siguientes datos de la tarjeta de crédito:

Silencioso sign-in

La opción « sign-in » silenciosa permite la autenticación automática cuando ya existe una sesión válida con el proveedor de identidad. Si el usuario está autenticado en otra pestaña del navegador o en otra aplicación, se reutilizará la sesión existente y el usuario iniciará sesión sin que se le pida que introduzca sus credenciales.

Esta función depende de que se mantenga una cookie del navegador para conservar el estado de « logged-in ». Utiliza el mismo punto final de autorización tanto para el inicio de sesión estándar como para los flujos de SSO. Cuando se detecta una sesión activa, la solicitud se redirige a una URL de redirección de SSO específica sin que se active la reautenticación.

El SSO solo se puede activar en puntos de venta que no estén sujetos a los requisitos de cumplimiento del Reglamento General de Protección de Datos (RGPD) de la UE, debido a la persistencia de la sesi cookie-based. Tendrás que configurar nuestra URL de redireccionamiento en los ajustes de tu proveedor de identidad para habilitar el flujo de SSO. Expedia Te daré la URL de redirección durante la integración.

Lista de redes permitidas

Esta lista define los requisitos para una comunicación segura entre tu sitio de plantilla y los entornos de Expedia. Te daremos los rangos de IP de salida de AWS, junto con las direcciones IP que se usan para las pruebas locales o en lower-environment. Tienes que añadir estas direcciones IP a la lista de permitidas para asegurarte de que no se bloquee el tráfico entrante procedente de Expedia.

También tendrás que facilitarnos las direcciones IP de salida de tu organización para que podamos añadirlas a la lista de permitidos por nuestra parte.

Nota:. Si estas direcciones IP no se añaden a las listas de permitidos (en cualquiera de los dos lados o en ambos), habrá problemas de conectividad tanto en las llamadas SSO salientes como en las entrantes.

Expedia puntos finales

Tendrás que configurar el « redirect_uri » en tu proveedor de identidad con estos valores para habilitar las llamadas de autorización:

• {WLTP domain}/sso/auth: Punto final de redirección de SSO tras la llamada de autorización en el flujo de inicio de sesión
• {WLTP domain}/validateCurrentSession: Punto final de redirección de SSO tras la llamada de autorización para el flujo silencioso de sign-in

Nota: Expedia ha establecido un tiempo de espera máximo estándar para las sesiones de 60 minutos. Pasados 60 minutos, tendrás que actualizar el token.