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 エンドポイントは認証と承認に使用されます。この関数は、次のような場合、クライアントに認可許可または認可コードを返します。logged-in. ブラウザのリダイレクトです。

リクエストパラメーター

レスポンスパラメーター

認証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
}

ユーザー情報エンドポイント

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 へのディープリンク。

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