パブリック SLAS クライアントのユースケース

SLAS のセットアップと最初のリクエストを行う方法は、入門ガイドで説明されています。Shopper API の認可を参照してください。

以下のユースケースは、さまざまなログインシナリオで、SLAS を使用して、パブリッククライアントが Shopper API に認可アクセスを行えるようにする方法を示しています。

前述したように、パブリッククライアントは、登録ユーザーのクライアントシークレットをセキュアに保存できない 買い物アプリです。PWA Kit で構築されたシングルページアプリ、Android または iOS アプリ、ゲートウェイをもたないモバイルアプリなどは、パブリッククライアントとしてプロビジョニングする必要があります。

各ユースケースは、ゲストユーザー (ログインなし)、フェデレートログイン、B2C ログインという異なるログインシナリオを示しています。

3 つのユースケースはすべて OCAPI の /baskets エンドポイントを使用していますが、前述したように、SLAS アクセストークンは Shopper API の任意の エンドポイントで使用できます。

認証フローの各ステップには番号を振ってあり、3 つのユースケースすべてについて詳細に説明しています。また、番号のついたステップは図解しています。

API リクエストの方法の詳細については、API 仕様を参照してください。

これらのユースケースは、Postman コレクション Salesforce Commerce Cloud SLAS Use Cases (Salesforce Commerce Cloud SLAS のユースケース) を使用してインタラクティブに探索できます。

このユースケースでは、買い物客が最初にログインせずに商品を買い物カゴに追加したときにどのように処理されるかを説明します。OAuth 2.1 規格で定義されている authorization code grant (認可コード付与) のフローに従います。また、RFC7636 で定義されている proof key for code exchange (PKCE) を使用します。

関連ダイアグラム

  1. 買い物客は、Commerce Cloud の買い物アプリを開いてやりとりを始めます。

  2. 買い物アプリによって、code_verifier と code_challenge の 2 つの文字列が生成されます。

    • code_verifier 文字列はランダムな文字列です。
    • code_challenge は code_verifier 文字列を SHA-256 ハッシュでエンコードしたバージョンです。

  3. 買い物アプリは、SLAS API の /authorize エンドポイントにリクエストを出します。

    • 必須クエリパラメーター: hint=guest、response_type=code、client_id、code_challenge、redirect_uri。
    • redirect_uri パラメーターで、ログイン完了時にどのアプリのルートにリダイレクトするかを指定します。
    • オプションのクエリパラメーター: usid。ゲストユーザーの USID (Unique Shopper Identifier: 一意の買い物客識別子) がすでにある場合は、それを渡せます。USID がない場合は SLAS によって生成されます。
    • ベストプラクティス: 以前のゲストログインで買い物客のために使用した USID を再利用します。これにより、以前のすべてのログイン試行にそのユーザーを関連付け、パーソナライズできるようになります。

  4. エンドポイントから認可コードが返され、redirect_uri 経由で買い物アプリにリダイレクトされます。必要であれば、クエリパラメーターを介して USID が返されます。

  5. 買い物アプリは、SLAS API の /token エンドポイントにリクエストを出します。

    • 認可ヘッダーは必要ありません。
    • 必須クエリパラメーター: grant_type=authorization_code_pkce、code_verifier、code,client_id、redirect_uri。
    • 推奨クエリパラメーター (将来的に必須となる): channel_id。

  6. エンドポイントのレスポンスに含まれるアクセストークンは、JSON Web Token (JWT)、customer_id 文字列、USID、およびリフレッシュトークンの形式を取ります。

    • JWT には、Einstein tracking API を呼び出すために使用できる enc_user_id 文字列も含まれます。ゲストユーザーの場合は、代わりに USID を使用します。

  7. 買い物アプリは SLAS API の /getJwksUri エンドポイントにリクエストを出し、SLAS API によって発行された JWT を検証するためのキーを取得します。

  8. エンドポイントは、現在、過去、将来の公開キーを含む JSON Web Key Set (JWKS) で応答します。

  9. 買い物アプリは、SLAS API によって発行された Shopper JWT を検証するためにキーセットを使用します。

  10. ゲスト買い物客が商品を買い物カゴに入れます。

  11. 買い物アプリは、OCAPI の /baskets エンドポイントにリクエストを行い、ヘッダーに SLAS のアクセストークンを渡します。

  12. Baskets API は、ゲストユーザーに関連付けられた customer_id の文字列をもつ買い物カゴを保存します。

このユースケースでは、買い物客が商品を買い物カゴに入れる前に、サードパーティの ID プロバイダーを使ってログインした場合の処理を説明します。OAuth 2.1 規格で定義されている authorization code grant (認可コード付与) のフローに従います。また、RFC7636 で定義されている proof key for code exchange (PKCE) を使用します。

関連ダイアグラム

  1. 買い物客は Commerce Cloud の買い物アプリにログインし、認証を行うサードパーティの ID プロバイダー (IDP) を選択します。

  2. 買い物アプリによって、code_verifier と code_challenge の 2 つの文字列が生成されます。

    • code_verifier 文字列はランダムな文字列です。
    • code_challenge は code_verifier 文字列を SHA-256 ハッシュでエンコードしたバージョンです。

  3. 買い物アプリは、SLAS API の /authorize エンドポイントにリクエストを出します。

    • 必須クエリパラメーター: hint、response_type=code、client_id、code_challenge、redirect_uri。
    • hint パラメーターで、ID プロバイダーの名前を指定します。
    • redirect_uri パラメーターで、ログイン完了時にどのアプリのルートにリダイレクトするかを指定します。

  4. SLAS API によって、ID プロバイダーのログインページにリダイレクトされます。

  5. 買い物客は認証情報を入力し、同意します。

  6. 正常にログインすると、SLAS API から認可コードが返され、買い物アプリにリダイレクトされます。

  7. 買い物アプリは、SLAS API の /token エンドポイントにリクエストを出します。

    • 認可ヘッダーは必要ありません。
    • 必須クエリパラメーター: grant_type=authorization_code_pkce、code_verifier、code、client_id、redirect_uri。

  8. エンドポイントのレスポンスに含まれるアクセストークンは、JSON Web Token (JWT)、customer_id 文字列、USID、およびリフレッシュトークンの形式を取ります。

    • JWT には、Einstein tracking API を呼び出すために使用できる enc_user_id 文字列も含まれます。

  9. 買い物アプリは SLAS API の /getJwksUri エンドポイントにリクエストを出し、SLAS API によって発行された JWT を検証するためのキーを取得します。

  10. エンドポイントは、現在、過去、将来の公開キーを含む JSON Web Key Set (JWKS) で応答します。

  11. 買い物アプリは、SLAS API によって発行された Shopper JWT を検証するためにキーセットを使用します。

  12. 登録買い物客が商品を買い物カゴに入れます。

  13. 買い物アプリは、OCAPI の /baskets エンドポイントにリクエストを行い、ヘッダーに SLAS のアクセストークンを渡します。

  14. Baskets API は、登録買い物客に関連付けられた customer_id の文字列をもつ買い物カゴを保存します。

このユースケースでは、買い物客が商品を買い物カゴに入れる前に、B2C Commerce インスタンスが管理する認証情報でログインした場合の処理を説明します。OAuth 2.1 規格で定義されている authorization code grant (認可コード付与) のフローに従います。また、RFC7636 で定義されている proof key for code exchange (PKCE) を使用します。

関連ダイアグラム

  1. 買い物客は Commerce Cloud の買い物アプリにログインし、買い物アプリから直接認証する方法を選択します。

  2. 買い物アプリによって、code_verifier と code_challenge の 2 つの文字列が生成されます。

    • code_verifier 文字列はランダムな文字列です。
    • code_challenge は code_verifier 文字列を SHA-256 ハッシュでエンコードしたバージョンです。

  3. 買い物アプリは、SLAS API の /login エンドポイントにリクエストを出します。

    • リクエストには、文字列 <shopperUserID>:<shopperPassword> を Base64 でエンコードしたバージョンを含む認可ヘッダーを含める必要があります。(文字列をエンコードする前に、<shopperUserID> と <shopperPassword> を必ず実際の値に置き換えてください)。
    • ヘッダー値の例: Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
    • 必須クエリパラメーター: code_challenge、usid、channel_id、client_id、redirect_uri。

  4. SLAS API は、リダイレクト URI にリダイレクトし、認可コードを返します。

  5. 買い物アプリは、SLAS API の /token エンドポイントにリクエストを出します。

    • 認可ヘッダーは必要ありません。
    • 必須クエリパラメーター: grant_type=authorization_code_pkce、code_verifier、code、client_id、redirect_uri。

  6. エンドポイントのレスポンスに含まれるアクセストークンは、JSON Web Token (JWT)、customer_id 文字列、USID、およびリフレッシュトークンの形式を取ります。

    • JWT には、Einstein tracking API を呼び出すために使用できる enc_user_id 文字列も含まれます。

  7. 買い物アプリは SLAS API の /getJwksUri エンドポイントにリクエストを出し、SLAS API によって発行された JWT を検証するためのキーを取得します。

  8. エンドポイントは、現在、過去、将来の公開キーを含む JSON Web Key Set (JWKS) で応答します。

  9. 買い物アプリは、SLAS API によって発行された Shopper JWT を検証するためにキーセットを使用します。

  10. 登録買い物客が商品を買い物カゴに入れます。

  11. 買い物アプリは、OCAPI の /baskets エンドポイントにリクエストを行い、ヘッダーに SLAS のアクセストークンを渡します。

  12. Baskets API は、登録買い物客に関連付けられた customer_id の文字列をもつ買い物カゴを保存します。

このユースケースでは、買い物客がサードパーティ IDP によって管理されている外部プロフィールを使用してログインした場合の処理を説明します。

関連ダイアグラム

  1. 買い物客が、サードパーティの IDP によって管理される認証情報を使用して、Commerce Cloud 買い物アプリにログインします。
  2. 買い物アプリが /authorize エンドポイントにリクエストを行います。
  3. SLAS API はサードパーティの IDP にリダイレクトします。
  4. サードパーティ IDP は、ログインが成功すると SLAS ログイン API へのコールバックを行います。
  5. SLAS サービスは、サードパーティの IDP に対して、IDP トークンと shopper/user 情報を取得するようにリクエストします。
  6. SLAS サービスは、外部プロフィールエンドポイントに対して、B2C Commerce で買い物客のサードパーティ認証情報を使用してレコードを作成するようにリクエストします。
  7. B2C Commerce で外部プロフィールが正常に作成されると、対応するユーザーエントリが SLAS に保持されます。

これでパブリッククライアントでのユースケースについて理解を深めることができましたので、次はプライベート SLAS クライアントのユースケースについて学習しましょう。

SLAS をアプリに組み込む準備ができたら、API 参照資料で SLAS エンドポイントの完全な技術仕様について確認してみましょう。