プライベート SLAS クライアントのユースケース

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

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

前述したように、プライベートクライアントは、クライアントシークレットをセキュアに保存できる買い物アプリです。フルスタック Web アプリと、BFF (backend-for-frontend) をもつすべての買い物アプリは、プライベートクライアントとしてプロビジョニングする必要があります。

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

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

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

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

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

このユースケースでは、買い物客が最初にログインせずに商品を買い物カゴに追加したときにどのように処理されるかを説明します。OAuth 2.1 規格で定義されている Client Credentials Grant (クライアント認証情報付与) のフローに従います。

関連ダイアグラム

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

  2. 買い物アプリは、SLAS API の /token エンドポイントを使用してアクセストークンをリクエストします。

    • リクエストには、文字列 <clientID>:<clientSecret> を Base64 でエンコードしたバージョンを含む認可ヘッダーを含める必要があります。(文字列をエンコードする前に、<clientID> と <clientSecret> を必ず実際の値に置き換えてください)。
    • ヘッダー値の例: Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW。
    • クライアント ID とクライアントシークレットは、SLAS 組織管理者がアプリ用にプロビジョニングする必要があります。詳細については、SLAS Admin API を参照してください。
    • 必須クエリパラメーター: grant_type=client_credentials。
    • 推奨クエリパラメーター (将来的に必須となる): channel_id。
    • オプションのクエリパラメーター: usid。ゲストユーザーの USID (Unique Shopper Identifier: 一意の買い物客識別子) がすでにある場合は、それを渡せます。USID がない場合は SLAS によって生成されます。
    • ベストプラクティス: 以前のゲストログインで買い物客のために使用した USID を再利用します。これにより、以前のすべてのログイン試行にそのユーザーを関連付け、パーソナライズできるようになります。

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

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

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

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

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

関連ダイアグラム

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

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

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

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

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

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

  6. 買い物アプリは、SLAS API の /token エンドポイントを使用してアクセストークンをリクエストします。

    • リクエストには、文字列 <clientID>:<clientSecret> を Base64 でエンコードしたバージョンを含む認可ヘッダーを含める必要があります。(文字列をエンコードする前に、<clientID> と <clientSecret> を必ず実際の値に置き換えてください)。
    • ヘッダー値の例: Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW。
    • クライアント ID とクライアントシークレットは、SLAS 組織管理者がアプリ用にプロビジョニングする必要があります。詳細については、SLAS Admin API を参照してください。
    • 必須クエリパラメーター: grant_type=authorization_code。

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

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

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

  10. 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 エンドポイントにリクエストを出します。

    • リクエストには、文字列 <clientID>:<clientSecret> を Base64 でエンコードしたバージョンを含む認可ヘッダーを含める必要があります。(文字列をエンコードする前に、<clientID> と <clientSecret> を必ず実際の値に置き換えてください)。
    • ヘッダー値の例: Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW。
    • クライアント ID とクライアントシークレットは、SLAS 組織管理者がアプリ用にプロビジョニングする必要があります。詳細については、SLAS Admin API を参照してください。
    • 必須クエリパラメーター: grant_type=authorization_code_pkce、code_verifier、code、client_id、redirect_uri。

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

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

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

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

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

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

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