Visão geral de SSO do OpenID Connect

O OpenID Connect (OIDC) é um protocolo de autenticação com base no OAuth 2.0 que foi adotado por grandes empresas de tecnologia.

Saiba mais sobre o OIDC

SSO básico

Sejam quais forem as opções de recursos selecionadas, os requisitos de configuração do SSO básico são os mesmos. Adicionar implementações de cartão de crédito ou programa de fidelidade exige mais informações.

Requisitos de configuração

Para configurar o acesso de SSO do OIDC ao seu modelo de site, alguns elementos são necessários, incluindo:

• APIs (authorize, token, userProfile, JWKS)
• ClientId
• Segredo do cliente
• ResponseMode
• isNonceEnabled
• customerDetailsAPIKey (se disponível)

Fluxos de autorização

Endpoint de autorização

O ponto de extremidade GET /authorize é usado para autenticação e autorização. Retorna uma autorização ou código assim que o usuário faz login. Trata-se de um redirecionamento do navegador que o direciona a enviar suas credenciais para autenticação.

Parâmetros de solicitação

Parâmetros de resposta

Exemplo de URL de autorização

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 retorno de chamada de exemplo

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

Endpoint de token

O endpoint POST /tokené uma chamada de API de backend usada para obter um token de acesso e um token de ID, apresentando uma concessão ou código de autorização.

Parâmetros de solicitação

Cabeçalhos de solicitação

Parâmetros de resposta

ID_token

O ID_token é um JSON Web Token (JWT) que inclui partes de informações de autenticação chamadas de declarações. As soluções de modelo da Expedia usam as declarações header, payload e signature, conforme a tabela a seguir.

Declarações de cabeçalho

Declarações de conteúdo

Declarações de assinatura

Validação da assinatura: A assinatura será validada em relação à chave apropriada (recuperada usando JWKS endpoint) para aquele client_ide algoritmo.

Token de exemplo 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}'

Exemplo de resposta do token

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

Endpoint de informações do usuário

O endpoint GET /userinfoé uma chamada de API de backend que retorna declarações sobre o usuário autenticado com base no token de acesso fornecido. Retorna dados do perfil do usuário, que são usados ​​para incluir o nome do cliente no cabeçalho da conta do site, o que permite carregar informações sobre os níveis de fidelidade por meio da conta do programa.

Nota: Se os parâmetros obrigatórios não forem fornecidos na resposta, isso causará problemas com a experiência do cliente no site. Por exemplo, o nome do cliente não será exibido no site do modelo e as informações da conta do programa necessárias para a conexão com a inscrição no programa de fidelidade da Expedia estarão ausentes.

Cabeçalhos de solicitação

Resposta

Exemplo de informações do usuário CURL

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

Exemplo de resposta de informações do usuário

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

Inclusão de programas de fidelidade

Como parte do seu modelo de site, você pode incluir a possibilidade de os clientes ganharem pontos de fidelidade em suas compras de viagens. Se desejar, seu modelo também pode permitir que os clientes use seus pontos de fidelidade acumulados para comprar viagens.

Os mesmos requisitos de configuração da implementação padrão se aplicam, assim como muitos dos valores. Somente os que são diferentes estão incluídos aqui.

Além do user informationpadrão, a configuração do programa de fidelidade incluirá os seguintes valores.

programAccount

Valor

Restrição do cartão de pagamento

Podemos configurar seu site para que os viajantes precisem usar o cartão de crédito da sua organização para fazer reservas. Isso é opcional, pois todas as soluções de modelo podem aceitar todos os principais cartões de crédito ou débito (e, nos EUA, PayPal).

Segurança e armazenamento do cartão de crédito

Se você optar por exigir a compra usando o cartão de crédito personalizado da sua organização, queremos que sinta segurança. Lidamos com isso das seguintes maneiras:

• As informações do cartão são armazenadas em um formato tokenizado que é vinculado ao perfil do cliente na Expedia. O armazenamento nunca é feito sem criptografia.
• Nenhum ser humano tem acesso aos dados não criptografados do cartão, e a descriptografia só acontece com credenciais seguras do IAM.
• Quando um cartão é pré-carregado na página de pagamento, somente a descrição do cartão fica visível, não o número.
• O cliente deve inserir o código de segurança do cartão para concluir a reserva com o cartão armazenado.

Requisitos de configuração

Além dos requisitos de configuração da implementação padrão, adicionar o cartão de crédito significa que vamos precisar de:

• Um ponto de extremidade a ser usado para o parâmetro AuthnRequest.
• A sua chave pública para verificação de assinatura.

Vamos usar a chave privada da Expedia para assinar o conteúdo do AuthnRequest e a nossa chave pública para fornecer validação de assinatura para você.

Detalhes de conteúdo

Junto com os atributos descritos na implementação padrão, quando um cliente faz login no seu site, o SSO do cartão de crédito inicia o envio de dois parâmetros de transação para o ponto de extremidade seguro de SSO da Expedia:

• API de informações do usuário: conteúdo de resposta codificado e assinado com asserções assinadas e criptografadas.
• RelayState: um deep link para o URL da página de chegada.

O conteúdo também vai conter os seguintes dados do cartão de crédito:

Silencioso sign-in

O parâmetro silencioso sign-in permite a autenticação automática quando já existe uma sessão válida com o provedor de identidade. Se o usuário estiver autenticado em outra aba do navegador ou aplicativo, a sessão existente será reutilizada e o usuário fará login sem precisar inserir suas credenciais.

Essa funcionalidade depende da manutenção de um cookie do navegador para preservar o estado logged-in. Ele utiliza o mesmo ponto de extremidade de autorização tanto para o login padrão quanto para os fluxos de SSO (Single Sign-On). Quando uma sessão ativa é detectada, a solicitação é redirecionada para um URL de redirecionamento SSO designado, sem acionar uma nova autenticação.

O SSO só pode ser ativado para pontos de venda que não estejam sujeitos aos requisitos de conformidade do Regulamento Geral de Proteção de Dados (RGPD) da UE, devido à persistência de sessão cookie-based. Você precisará configurar nosso URL de redirecionamento nas configurações do seu provedor de identidade para habilitar o fluxo de SSO. A Expedia fornecerá o URL de redirecionamento durante a integração.

Lista de permissões de rede

Esta lista define os requisitos para comunicação segura entre o seu site modelo e os ambientes da Expedia. Forneceremos intervalos de IP de saída da AWS, juntamente com endereços IP usados ​​para testes locais ou lower-environment. Você precisa adicionar esses IPs à lista de permissões para garantir que o tráfego de entrada da Expedia não seja bloqueado.

Você também precisará compartilhar conosco os endereços IP de saída da sua organização para que possamos adicioná-los à lista de permissões em nosso sistema.

Nota: Se esses IPs não forem adicionados às listas de permissão (em um ou ambos os lados), haverá problemas de conectividade nas chamadas SSO de entrada e saída.

Pontos de extremidade da Expedia

Você precisará configurar o redirect_urino seu provedor de identidade com esses valores para habilitar chamadas de autorização:

• {WLTP domain}/sso/auth: Ponto de extremidade de redirecionamento SSO após a chamada de autorização para o fluxo de login
• {WLTP domain}/validateCurrentSession: Endpoint de redirecionamento SSO após a chamada de autorização para o fluxo silencioso sign-in

Nota: A Expedia definiu um tempo limite máximo padrão de sessão de 60 minutos. Após 60 minutos, você precisará atualizar o token.