Shopper Login (SLAS) の概要

Shopper Login and API Access Service (SLAS) を使用すると、B2C Commerce API と Open Commerce API (OCAPI) の Shopper API にセキュアにアクセスできます。

SLAS を設定するための管理ツールとして、SLAS Admin API と SLAS Admin UI の 2 つが用意されています。どちらの管理ツールでもアクセスコントロールに Account Manager を使用し、SLAS Organization Administrator (SLAS 組織管理者) の役割をもち、B2C Commerce インスタンスに正しいフィルターが設定されている必要があります。

SLAS Admin UI にアクセスするには、次の URL の {{short-code}} を、自社の B2C Commerce インスタンスで使用されているショートコードに置き換えます。

Commerce Cloud ショートコードの詳細については、構成値ガイドを参照してください。

高ボリュームの状況で SLAS を使用する場合のアドバイスについては、Salesforce デベロッパーブログの Shopper Login API: Techniques and Tricks to Get the Most Out of High-Volume Holidays (Shopper Login API: 高ボリュームのホリデー期間を最大限に活用するためのテクニックとコツ) の記事を参照してください。

認可されたリクエストを SLAS に対して行うには、各アプリケーションを 1 つまたは複数の SLAS クライアントと関連付ける必要があります。各 SLAS クライアントは 1 つの SLAS テナントに登録され、各 SLAS テナントは 1 つの B2C Commerce インスタンスに関連付けられます。

SLAS クライアントは、パブリックまたはプライベートの 2 つのタイプのいずれかを使用して作成できます。アプリケーションに適切なクライアントタイプを選択するために最も重要なことは、そのクライアントがクライアントシークレットを安全に保存できると信頼できるかどうかです。クライアントを信頼できる場合はプライベートクライアントを使用し、信頼できない場合はパブリッククライアントを使用してください。

たとえば、SLAS と直接通信するモバイルアプリは、買い物客のデバイスにクライアントシークレットを保存する必要がありますが、これは安全ではありません。このため、ほとんどのモバイルアプリはパブリッククライアントを使用します。それに対し、BFF (Backend for Frontend) システムを備えたモバイルアプリは、買い物客のデバイスがアクセスできない安全な場所にクライアントシークレットを保存 できます。ですから、BFF システムを備えたアプリはプライベートクライアントを使用できます。

次の表は、最も一般的なタイプのアプリケーションで使用されるクライアントタイプをまとめたものです。

SLAS API は、OAuth 2 規格で定義された付与タイプに基づいています。

アクセストークンリクエストに使用される付与タイプは、SLAS クライアントのタイプ (パブリックまたはプライベート) と買い物客の認証メソッドに依存します。

ほとんどの SLAS クライアントは getAccessToken エンドポイントでアクセストークンをリクエストし、ShopperToken を受け取ります。

信頼できるシステムは getTrustedSystemAccessToken エンドポイントを使用し、ShopperTsob トークン を受け取ります。このトークンは、信頼できるシステムがユーザーの代理でリクエストを行えるように、追加の機能を備えています。

次の表は、SLAS クライアントとユーザー認証メソッドのタイプごとに使用されるさまざまな付与タイプとトークンタイプをまとめたものです。

ShopperToken をリクエストするには、getAccessToken のエンドポイントを使用します。ShopperTokenTsob をリクエストするには、getTrustedSystemAccessToken のエンドポイントを使用します。

両エンドポイントは、認証に成功すると以下を返します。

• JSON Web Token (JWT) 形式のアクセストークン
• customer_id 文字列
• 一意の買い物客識別子 (USID)
• リフレッシュトークン

アクセストークンは 30 分間有効です。このトークンは、発行元の SLAS API クライアントの範囲の対象となる B2C Commerce API エンドポイントにリクエストを行うときに使用できます。また、このトークンで、SLAS API クライアント ID が許可されている Open Commerce API エンドポイントをリクエストできます。発行されたインスタンスおよびサイトから API をリクエストする目的でのみ使用可能です。

リフレッシュトークンを使用して、新しいアクセストークンをリクエストできます。Production (本番) テナントの場合、リフレッシュトークンは、登録済みの買い物客においては 90 日間、ゲストにおいては 30 日間有効です。本番以外のテナントの場合、リフレッシュトークンは 9 日間有効です。リフレッシュトークンを使用すると、その後発行されるトークンの有効期間は、その有効期間分延長されます。

パブリッククライアントを使用して発行されたリフレッシュトークンは、1 回限り使用できます。リフレッシュトークンが使用されると、レスポンスで新しいトークンが返されます。プライベートクライアントを使用して発行されたリフレッシュトークンは、複数回使用できる場合があります。同じリフレッシュトークンは、レスポンスに返されます。

• 買い物客がパスワードを変更すると、パスワード変更前に付与されたアクセストークンは、B2C Commerce API と OCAPI の両方から拒否されます。パスワード変更後は、リフレッシュトークンを使って新しいアクセストークンを取得するか、買い物客に再度認証するよう促してください。
• SLAS から返される JWT には多数のクレームが含まれています。クレームを調査するコードを作成する場合は、順序に依存しないようにしてください。クレームが追加される可能性があるためです。
• アクセストークンを使用すると、買い物客に代わって操作を行えるようになります。アカウントに紐づく E メールの更新など、実行するアクションは機密性の高いものになる可能性があります。買い物客を保護するために必要な予防措置を常に講じてください。

SLAS でサポートされるレート制限は次のとおりです。

• Production (本番) インスタンスでは、1 テナントにつき 24,000 RPM (Requests Per Minute: 1 分あたりのリクエスト数)。
• Production (本番) 以外のインスタンスでは、1 テナントにつき 500 RPM。
• getJwksUri と getWellknownOpenidConfiguration のエンドポイントでは 25 RPM。

レート制限に達すると、SLAS は Retry-After HTTP レスポンスヘッダーを含む HTTP 429 Too Many Requests で応答します。Retry-After ヘッダーの値には、リクエストを再試行するまでの待機時間 (秒単位) が設定されています。

クライアントコードはこのリスポンスを処理できる必要があります。次のリクエストが確実に成功するよう、再試行する前に必ず指定された時間待機してください。

authenticateCustomer を含む一部の SLAS は、関連付けられている B2C Commerce インスタンスと通信します。そのインスタンスを使用できない場合、これらのエンドポイントへの呼び出しは失敗します。

dw.ocapi.shop.customer.auth.* のフックを含む SCAPI フックは、SLAS 呼び出しと競合する可能性があります。SLAS 呼び出しが予期せず失敗する場合、B2C Commerce ログでフック呼び出しエラーがないか確認してください。

入門ガイドの Shopper API の認可の指示に従って、パブリック SLAS クライアントまたはプライベート SLAS クライアントを設定します (この設定が完了していない場合)。

SLAS クライアントの設定が完了したら、メインの SLAS API と SLAS Admin API の両方を使用する方法について説明する以下の SLAS ガイドを参照してください。

• パブリック SLAS クライアントのユースケース (メインの SLAS API)
• プライベート SLAS クライアントのユースケース (メインの SLAS API)
• SLAS ID プロバイダー (SLAS Admin API)

SLAS API の機能に関する技術的な詳細については、参照資料セクションの次の API 仕様を参照してください。

• SLAS API
• SLAS Admin API