シームレスなユーザー セッション（ポイント特典へのアクセス、パーソナライズされた特典など）と認証済みの購入手続きを有効にするには、OAuth 2.0 を使用して ID リンク機能を実装する必要があります。ID リンクを実装しない場合は、ゲスト購入をサポートする必要があります。
プライバシー規制と同意の運用方法に関するご質問は、法務チームにご相談ください。
コア要件
- プロトコル: OAuth 2.0 認可コードフロー（RFC 6749 2.3.1）を実装します。
- クライアント認証: トークン エンドポイントで HTTP Basic Authentication（
client_secret_basic）をサポートする必要があります。 - スコープ: このセクションで定義されている標準の UCP スコープをサポートする必要があります。
- ディスカバリ: プラットフォームがエンドポイントを検出できるようにするには、
/.well-known/oauth-authorization-server（RFC 8414）でメタデータ ファイルをホストする必要があります。
スコープ
次のスコープを実装する必要があります。このスコープにより、すべてのチェックアウト ライフサイクル オペレーション（取得、作成、更新、削除、キャンセル、完了）に対する権限が付与されます。
- スコープ名:
ucp:scopes:checkout_session
ユーザー エクスペリエンス: リクエストされたスコープは、1 つのバンドルされた同意画面として提示する必要があります（例: 「Google にチェックアウト セッションの管理を許可する」）を有効にする必要があります。
Google Streamlined Linking
Google の簡素化されたリンクは、標準の OAuth 2.0 に追加できるオプションです。JWT アサーションを利用して、OAuth 2.0 トークン エンドポイント（check、create、get インテント）でインテント チェックとトークン交換を組み合わせます。
シームレスなユーザー エクスペリエンスを実現するには、Google Streamlined Linking をおすすめします。これにより、ユーザーは Google インターフェースを離れることなく、Google プロフィールを使用してアカウントをリンクしたり、新しいアカウントを作成したりできます。フローは Google の UI 内で完全に発生するため、リンク フロントエンドは必要ありません。これにより、開発オーバーヘッドが削減され、ブラウザのリダイレクトが不要になり、コンバージョン率が向上します。
- 仕様: 実装は、簡素化されたリンクの要件に準拠する必要があります。
- 標準: RFC 7523 のコンセプトを取り入れていますが、セキュリティを強化するために異なります。
認可サーバー メタデータ（JSON の例）
この JSON オブジェクトは https://[your-domain]/.well-known/oauth-authorization-server で公開する必要があります。
例:
{
"issuer": "https://merchant.example.com",
"authorization_endpoint": "https://merchant.example.com/oauth2/authorize",
"token_endpoint": "https://merchant.example.com/oauth2/token",
"revocation_endpoint": "https://merchant.example.com/oauth2/revoke",
"scopes_supported": [
"ucp:scopes:checkout_session"
],
"response_types_supported": [
"code"
],
"grant_types_supported": [
"authorization_code",
"refresh_token"
],
"token_endpoint_auth_methods_supported": [
"client_secret_basic"
],
"service_documentation": "https://merchant.example.com/docs/oauth2"
}