OpenID Connect SSO の概要

OpenID Connect (OIDC) は OAuth 2.0 ベースの認証プロトコルで、大手テクノロジー企業で採用されています。

>> OIDCについて詳しくはこちら

ベーシック SSO

選択した機能に関係なく、ベーシック SSO の設定要件は同じです。ロイヤルティまたはクレジット カードの実装を追加すると、追加情報が必要になります。

設定要件

テンプレートサイトへの OIDC SSO アクセスを適切に設定するには以下が必要です。

• API（authorize、token、userProfile, JWKS）
• ClientId
• クライアントシークレット
• ResponseMode
• isNounceEnabled
• customerDetailsAPIKey (利用可能な場合)

認証フロー

エンドポイントの認証

GET /authorize エンドポイントは認証と承認に使用されます。ユーザーがログインすると、認証グラントまたは認証コードが返されます。これは、認証のために認証情報を入力するよう誘導するブラウザのリダイレクトです。

リクエストパラメーター

レスポンスパラメーター

認証用URLの例

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の例

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

トークンエンドポイント

POST /tokenエンドポイントは、認証グラントまたはコードを提示することで、アクセストークンとIDトークンを取得するために使用されるバックエンドAPI呼び出しです。

リクエストパラメーター

リクエストヘッダー

レスポンスパラメーター

ID_token

ID_token は JSON Web トークン (JWT) で、クレームと呼ばれる認証情報の断片を含んでいます。以下の表のように、エクスペディアのテンプレートソリューションではクレームとして header、payload、signature を使用しています。

ヘッダークレーム

ペイロードクレーム

署名クレーム

署名の検証：そのJWKS endpoint およびアルゴリズムに対応する鍵（client_id を使用して取得）を用いて、署名の検証が行われます。

トークンのサンプル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}'

トークン応答の例

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

Userinfoエンドポイント

GET /userinfoエンドポイントは、指定されたアクセストークンに基づいて、認証済みユーザーに関するクレームを返すバックエンドAPI呼び出しです。この関数はユーザーのプロファイルデータを返します。このデータは、サイトのアカウントヘッダーに顧客名を表示するために使用され、それによってプログラムアカウントを通じて ロイヤルティ のティア情報を読み込むことができます。

注： レスポンスに必須パラメータが指定されていない場合、サイト上のユーザー体験に支障をきたすことになります。例えば、テンプレートサイトには顧客名が表示されず、エクスペディア側で ロイヤルティ への登録に接続するために必要なプログラムアカウント情報が欠落してしまいます。

リクエストヘッダー

レスポンス

ユーザー情報のサンプル（CURL）

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

Userinfoの応答例

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

ロイヤルティの追加

テンプレートサイトの一環として、お客様が旅行関連の購入で ロイヤルティ ポイントを獲得できる機能を組み込むことができます。ご希望であれば、テンプレートに、お客様が貯めた ロイヤルティ ポイントを使って旅行を購入できるようにすることも可能です。

>> ロイヤルティ ポイントについて詳しくはこちら

多くの値と同様に、標準実装と同じ設定要件が適用されます。異なるものだけをここに掲載します。

標準のuser information に加え、ロイヤルティプログラムの設定には、以下の値が含まれます。

programAccount

金額

支払いカードの制限

旅行者がご予約の際、貴団体のクレジットカードを使用しなければならないように、サイトを設定することができます。すべてのテンプレートソリューションですべての主要なクレジットカードまたはデビットカード、および (米国では) PayPal を受け付けることができるため、これは必須ではありません。

クレジットカードの安全性と保管

組織のカスタムクレジット カードを使用して購入することを義務付けた場合でも、心配は無用です。クレジットカードは次のように扱われます。

• 顧客のエクスペディアプロフィールにリンクされた、トークン化された形式でカード情報が保存されます。暗号化されていない状態で保存されることは決してありません。
• 人間は暗号化されていないカードデータにアクセスできず、安全な IAM ログイン情報を使用しないと復号化できなくなっています。
• カードがチェックアウトページにプリロードされると、カード番号ではなくカードの説明のみが表示されます。
• 保存されたカードで予約を完了する場合、顧客はカードのセキュリティコードを入力する必要があります。

設定要件

標準実装の設定要件に加え、クレジットカードが追加されると以下が必要になります。

• AuthnRequest パラメーターに使用するエンドポイント
• 署名検証用の公開鍵

エクスペディアでは自社の秘密鍵を使用して AuthnRequest ペイロードに署名し、貴社側で署名検証を実行してもらうためにエクスペディアの公開鍵を使用します。

ペイロードの詳細

顧客がサイトにログインすると、クレジットカード SSO では、標準実装で説明されている属性とともに、セキュアなエクスペディア SSO エンドポイントに 2 つの取引パラメーターを送信します。

• ユーザー情報 API : 署名され暗号化されたアサーションを持つ、エンコードされ署名されたレスポンスペイロード。
• RelayState : ランディングページ URL へのディープリンク。

>> ユーザー情報APIの詳細はこちら

ペイロードには次のクレジットカードの詳細も含まれます。

サイレントsign-in

「sign-in」をサイレントモードに設定すると、IDプロバイダーとの間で有効なセッションがすでに存在する場合、自動認証が行われます。ユーザーが別のブラウザタブやアプリケーションで認証済みの場合、既存のセッションが再利用され、認証情報の入力を求められることなくログインされます。

この機能は、logged-inの状態を維持するために、ブラウザのクッキーを保持することに依存しています。標準ログインとSSOフローの両方で、同じ認証エンドポイントが使用されます。アクティブなセッションが検出されると、再認証を行わずに、リクエストは指定されたSSOリダイレクトURLへリダイレクトされます。

cookie-basedのセッション保持機能のため、SSOを有効にできるのは、EUの一般データ保護規則（GDPR）の遵守要件の対象とならない販売拠点に限られます。SSOフローを有効にするには、IDプロバイダーの設定で当社のリダイレクトURLを設定していただく必要があります。エクスペディアは、連携の際にリダイレクトURLを提供いたします。

ネットワークの許可リスト

このリストでは、テンプレートサイトとエクスペディアの環境間での安全な通信に関する要件を定義しています。AWSのアウトバウンドIP範囲に加え、ローカルまたはlower-environmentでのテストに使用されるIPアドレスをご提供いたします。エクスペディアからの着信トラフィックがブロックされないようにするには、これらのIPアドレスを許可リストに追加する必要があります。

また、弊社側で許可リストに追加できるよう、貴組織の送信元IPアドレスをお知らせいただく必要があります。

注： これらのIPアドレスが（どちらか一方または双方の）許可リストに追加されていない場合、送信および受信の両方のSSO呼び出しにおいて接続上の問題が発生します。

エクスペディアのエンドポイント

認証呼び出しを有効にするには、IDプロバイダーの「redirect_uri」を以下の値で設定する必要があります：

• {WLTP domain}/sso/auth: ログインフローにおける認証呼び出し後のSSOリダイレクトエンドポイント
• {WLTP domain}/validateCurrentSession: サイレントsign-inフローにおける認証呼び出し後のSSOリダイレクトエンドポイント

注： エクスペディアでは、セッションのタイムアウトを標準で60分に設定しています。60分が経過すると、トークンを更新する必要があります。