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 (autorizar, token, userProfile, JWKS)
• ClientId
• Segredo do cliente
• ResponseMode
• isNonceEnabled
• customerDetailsAPIKey (se disponível)

Fluxos de Autorização

Autorizar ponto final

O ponto de extremidade GET /authorize é usado para autenticação e autorização. Ele retorna uma concessão de autorização ou código para o cliente, caso o usuário seja logged-in. É um redirecionamento do navegador.

Parâmetros de solicitação

Parâmetros de resposta

URL de autorização de amostra

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

Ponto final do token

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

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_id e algoritmo.

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

Resposta de token de amostra

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

Ponto final do Userinfo

O ponto de extremidade GET /userinfo é uma chamada de API de backend que retorna declarações sobre o usuário autenticado com base no token de acesso fornecido.

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 do Userinfo

{
  "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 oferecer aos seus clientes a capacidade de juntar pontos de fidelidade nas compras de viagens. Se você quiser, o seu modelo também pode permitir que clientes usem 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 padrão user information, a configuração do programa de fidelidade incluirá os seguintes valores.

programAccount

Valor

Restrição do cartão de pagamento

Podemos configurar o seu site para que clientes usem 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: