前者の変換

サブアカウント認証で取得したセッションキー

はメインアカウントと同じセッションキーから取得されており、セッションキーに基づいて操作記録を区別することはできません;

サブアカウントのセッションキーはメインのセッションキーを識別します。メインアカウントとサブアカウントには異なるセッションキーが発行されます。サブアカウントはサブセッションキー（公式の最下層は親子関係を識別します);

セッションキー認証期間

#メイン セッションキーが使用されており、高リスクです。API の更新期間には、メイン アカウントの操作を実装する必要があります。

サブセッションキーの認証期間はメインセッションキーと一致しており、メインセッションキーとサブセッションキーは高リスクの読み取りと書き込みを個別に更新するためにサポートされています API 有効期間

#サブアカウント

有効期限API を呼び出すセッションキー

サードパーティ アプリケーションがサポートするサブアカウントのロジックをキャンセルした場合でも、保存されたサブアカウントを渡すことができます。 sessionkey が API オペレーションを呼び出し、バックグラウンドの sessionkey の有効期限が切れていない #

サードパーティ アプリケーションがサブアカウント ロジックのサポートをキャンセルすると、TOP は自身を制御し、サードパーティ アプリケーションが選択した場合、API リクエストを呼び出すすべてのサブセッションキーを禁止します。サブアカウントをサポートするために、TOP は MMP に従います 提供された承認関係はサブセッションキーを制御します;

##認可方式

TOPが提供するコンテナ認可またはoauth2認可メソッドを使用し、返されたパラメータパラメータを解析してユーザー情報を取得します

# は変更されず、同じ認証システムを使用します

推奨事項:

#

#ローカルにキャッシュされたメイン アカウントのセッションキーを部分的に使用します

提案:

現在のセッション キーを呼び出しのベースとして使用します。つまり、サブアカウントがログインするたびに、現在返されているセッション キーを使用します。ローカルで、特に高リスク API を呼び出す場合、タオバオ担当者は、API を呼び出すセッション キーの ID に基づいてログを直接記録し、ユーザーがクエリできるように公開します。まだメインの sessioneky を使用している場合、ログには正確なサブアカウントが記録されません (この部分の公式ログ情報は将来的に統合され、公開される予定です)。

「承認の管理」 TOPアプリ詳細の設定により、サブアカウントの権限でこの機能を使用できるようになります。

# アプリケーションがサブアカウント システムをサポートしているかどうかは、引き続き最初の条件として isv 設定が必要です。 ;

変換前、 はすでにサポートされていました。UP アプリケーション リストで新しいモードに切り替えることができます。詳細については、 「

サブアカウント認証の変換とアップグレードの概要>>ドキュメント後を参照してください。新しく作成されたアプリケーションがチェックされている場合の変換 選択すると、デフォルトで新しい認証モードが使用されます;