複製したGASで、AmazonSPAPIの認可フローを完了する

Question

前提

GASでAmazonSP-APIと連携している、スプレッドシートがあります。
これを、スプレッドシートをコピーしてそのまま配布しても同様に動作するようにしたいです。

しかし、SPAPIの認証方法（利用者セラーからアプリケーションへの認可）で詰まっている状態で、
認証ワークフローからすると、下記2点により難しいのではないかと考えています。
①複製後のスプレッドシートは最初Webアプリとしてデプロイされていないため、認証完了後のリダイレクトを受けられない
②リダイレクトURIが用意できたとしても、それをセラーセントラルのアプリケーション登録画面から設定しなければならない
→①は手順追加で対応できますが、②は運用上現実的ではない状態です

実現したいこと

コピー後も認証フローを完了させられるようなスプレッドシートにしたいので、
そのための仕組みづくりが可能であれば教えていただきたいです。
（セラーセントラルのアプリ登録でリダイレクトURIはこれにする、リダイレクト用アプリを用意する、設定するstateパラメータはこれにする等）
コピー後スプレッドシートに対しての個別設定は、Webアプリデプロイの操作のみ許容できます。

発生している問題・エラーメッセージ

単純にスプレッドシートをコピーしたもので認証しようとすると、
「SP-APIを承認」画面のConfirm後に下記メッセージが表示されます。

問題が発生しました
無効なリダイレクトURLを受信しました。使用されたリダイレクトURLを確認してください。

Amazonテクニカルサポートに連絡して、以下の情報をお知らせください。

App ID: amzn1.sp.solution.XXX
Error Code: MD5101

該当のソースコード

AUTH_ENDPOINT = 'https://XXX';
TOKEN_ENDPOINT = 'https://YYY';
CLIENT_ID = 'AAA';
CLIENT_SECRET = 'BBB';
APP_ID = 'CCC';

// OAuth2ライブラリ使用
function getService() {
  // OAuth 2.0承認サービスの生成
  return OAuth2.createService('spapi')

    .setAuthorizationBaseUrl(AUTH_ENDPOINT)   // 認可エンドポイント
    .setTokenUrl(TOKEN_ENDPOINT)              // トークンエンドポイント

    .setClientId(CLIENT_ID) // OAuthクライアントID
    .setClientSecret(CLIENT_SECRET) // OAuthクライアントシークレット

    .setParam('application_id', APP_ID)
    .setParam('version', 'beta')

    // OAuth2.0 承認後のコールバック関数名の設定
    .setCallbackFunction('authCallback')

    // 承認トークンを維持するプロパティーストアの設定
    .setPropertyStore(PropertiesService.getUserProperties())
}

/**
 * 最初のOAuth2承認の際のコールバック処理
 */
function authCallback(request) {
  var service = getService();
  // トークン取得用にパラメータを追加
  request.parameter['code'] = request.parameter.spapi_oauth_code;

  var authorized = service.handleCallback(request);
  if (authorized) {
    service.getAccessToken();
    return HtmlService.createHtmlOutput(`認証に成功しました。`);
  }
  return HtmlService.createHtmlOutput('認証に失敗しました。処理をやり直してください。');
}

/**
 * 認証用ダイアログ（html）表示
 * セラーセントラルの認証URLへリンクさせる
 */
function showDialog(){
  const service = getService();
  const url = service.getAuthorizationUrl();
  const tag_text = `<button type="button" class="btn btn-primary" onclick="window.open('${url}')">セラーセントラルで認証する</button>`;
  const html = HtmlService.createHtmlOutput(tag_text);
  SpreadsheetApp.getUi().showModalDialog(html, "認証ダイアログ");
}

//セラーセントラルのアプリ登録画面「OAuthリダイレクトURI」
https://script.google.com/macros/d/{コピー元スプレッドシートのスクリプトID}/usercallback

Comments

[qnoir]

・AUTH_ENDPOINT、TOKEN_ENDPOINT、CLIENT_ID、CLIENT_SECRET、APP_ID はソースコードに直書きされている、という理解でよろしいでしょうか。

・コピー元ファイルとコピー先ファイルで、CLIENT_ID、CLIENT_SECRET等は同一の値のままで運用する、という理解でよろしいでしょうか？

[thimone]

＞・AUTH_ENDPOINT、TOKEN_ENDPOINT、CLIENT_ID、CLIENT_SECRET、APP_ID はソースコードに直書きされている、という理解でよろしいでしょうか。
　→はい、コードに直書きされています。
＞・コピー元ファイルとコピー先ファイルで、CLIENT_ID、CLIENT_SECRET等は同一の値のままで運用する、という理解でよろしいでしょうか？
　→はい、同一の値のまま運用します。
よろしくお願いいたします。

Answer 1

＜下記は「試みたものの、結果としてはうまくいなかった例」になりますが、試行の過程として残しています。修正後の内容は、後述の「追記２」を参照してください＞
また、以下は、Amazon SP-API上での検証ではなく、他の一般的なOAuth2.0アプリケーションでの検証になります。


コピー元のスクリプトに doGet() を実装してWebアプリとしてデプロイし、コピー先からコピー元に対して、認証に必要な処理を呼び出せるようにしてはいかがでしょうか。

• DEPLOY_URL は、一度コピー元をデプロイして確定してしまえば、変更がない限りコピー先で変更する必要はありません。（コピー先ファイルごとのデプロイURLに変える必要はありません。）

• 逆に、コピー元のデプロイURLが変わってしまった場合は、コピー先ファイルに記載されているDEPLOY_URLを全部そのURLに修正しなければなりません。

　

• アクセストークンを使うときは、その都度、getToken() を呼び出してください。

　

• セラーセントラルのAPI登録画面でのリダイレクトURIは、コピー元のcallbackから変更する必要はありません。

　

• 複数ユーザーの同時アクセスに対応するためgetService関数の中でロックを設定しています。（ 参照 )

※実際にはその他の処理でも複数ユーザーによる競合が想定される部分には、ロックをかける必要があるかもしれません。
DEPLOY_URLを追加しているほか、showDialog() も一部修正しています。

AUTH_ENDPOINT = 'https://XXX';
他...
略

// ☆追加：コピー元のデプロイURL
const DEPLOY_URL = 'https://script.google.com/macros/s/***/exec'; 

// OAuth2ライブラリ使用
function getService() {
　略
    .setLock(LockService.getUserLock());  // 複数ユーザーが同時にトークンをリフレッシュしようとする可能性があるためロックを設定。
}

/**
 * 最初のOAuth2承認の際のコールバック処理
 */
function authCallback(request) {
　略
}

/**
 * 認証用ダイアログ（html）表示
 * セラーセントラルの認証URLへリンクさせる
 */
function showDialog() {
  const respjson = UrlFetchApp.fetch(DEPLOY_URL + '?authmode=true').getContentText();
  const response = JSON.parse(respjson);
  const url = response.authorizationUrl;
  const tag_text = `<button type="button" class="btn btn-primary" onclick="window.open('${url}')">セラーセントラルで認証する</button>`;
  const html = HtmlService.createHtmlOutput(tag_text);
  SpreadsheetApp.getUi().showModalDialog(html, "認証ダイアログ");
}

/**
 * アクセストークンを取得する。
 * @return : string
 *  認可済の場合：アクセストークン
 *  未認可の場合：'UNAUTHORIZED'
 */
function getToken() {
  const respjson = UrlFetchApp.fetch(DEPLOY_URL).getContentText();
  const response = JSON.parse(respjson);
  if (response.authorized) {
    return response.token;
  } else {
    return "UNAUTHORIZED"
  }
}

/**
 * クライアントからGETリクエストを受けた時に呼ばれる。
 * @return : JSON string
 *  呼び出し元に「authmode」パラメータが存在する場合
 *  　{"authorizationUrl : 認可URL}
 *  呼び出し元に「authmode」パラメータが存在せず、認可済みの場合
 * 　 {"anthorized" : true, "token" : アクセストークン} 
 *  呼び出し元に「authmode」パラメータが存在せず、未認可の場合
 *   {"authorized" : false}
 */
function doGet(e) {
  if (e.parameter.authmode)
    return toJson({ authorizationUrl: getService.getAuthorizationUrl() })

  if (getService.hasAccess())
    return toJson({ authorized: true, token: getService.getAccessToken() })

  return toJson({ authorized: false })
}

function toJson(content) {
  const output = ContentService.createTextOutput();
  output.setMimeType(ContentService.MimeType.JSON);
  output.setContent(JSON.stringify(content));
  return output;
}

/*個別処理を行う場合に必要となるアクセストークンは、getToken() で取得する。
 * 下記は注文を取得する例。
*/
function getOrders(){
  const access_token = getToken(); // アクセストークンの取得
  if (access_token==='UNAUTHORIZED) {
    console.log('認証が完了していないためアクセストークンを取得できません。' + 
      管理者に連絡して、認証・認可ファイルで再認証を行ってもらってください。');
  }
  略

  const end_point = 'https://sellingpartnerapi-eu.amazon.com';
　略
  const options = {
    'method': 'GET',
    'headers': {
      'x-amz-access-token': access_token,
      'x-amz-date': isoDate,
      'Authorization': 'AWS4-HMAC-SHA256 Credential=' + ACCESS_ID + '/' + credential_scope + ', SignedHeaders=' + signedheaders + ', Signature=' + signature,
    }
  }
  const orders = UrlFetchApp.fetch(end_point + canonicalURI + canonicalQueryString, options);
  console.log(orders);
}

---

説明　

　
上記は、実質的には下記の２つのコードを合体したものになります。
① original.gs
・認証・認可の処理を行う専用のファイル。
・アクセストークンを保管するとともに、②からの要求に応じて authorizationUrl やアクセストークンを渡す。

AUTH_ENDPOINT = 'https://XXX';
TOKEN_ENDPOINT = 'https://YYY';
CLIENT_ID = 'AAA';
CLIENT_SECRET = 'BBB';
APP_ID = 'CCC';

// OAuth2ライブラリ使用
function getService() {
　略
}

function authCallback(request) {
　略
}

function doGet(e) {
  if (e.parameter.authmode)
    return toJson({ authorizationUrl: getService.getAuthorizationUrl() })

  if (getService.hasAccess())
    return toJson({ authorized: true, token: getService.getAccessToken() })

  return toJson({ authorized: false })
}

function toJson(content) {
　略
}

② copy.gs
・実際の処理を行うファイル

const DEPLOY_URL = 'https://script.google.com/macros/s/***/exec';  // ①のデプロイURL

/**
 * 認証用ダイアログ（html）表示
 * セラーセントラルの認証URLへリンクさせる
 */
function showDialog() {
  const respjson = UrlFetchApp.fetch(DEPLOY_URL + '?authmode=true').getContentText();
  const response = JSON.parse(respjson);
  const url = response.authorizationUrl;
  const tag_text = `<button type="button" class="btn btn-primary" onclick="window.open('${url}')">セラーセントラルで認証する</button>`;
  const html = HtmlService.createHtmlOutput(tag_text);
  SpreadsheetApp.getUi().showModalDialog(html, "認証ダイアログ");
}

/**
 * アクセストークンを取得する。
 */
function getToken() {
  const respjson = UrlFetchApp.fetch(DEPLOY_URL).getContentText();
  const response = JSON.parse(respjson);
  if (response.authorized) {
    return response.token;
  } else {
    return "UNAUTHORIZED"
  }
}

/*個別処理を行う場合に必要となるアクセストークンは、getToken() で取得する。
 * 下記は注文を取得する例。
*/
function getOrders(){
  const access_token = getToken(); // アクセストークンの取得
  if (access_token==='UNAUTHORIZED) {
    console.log('認証が完了していないためアクセストークンを取得できません。' + 
      管理者に連絡して、認証・認可ファイルで再認証を行ってもらってください。');
  }
  略

  const end_point = 'https://sellingpartnerapi-eu.amazon.com';
　略
  const options = {
    'method': 'GET',
    'headers': {
      'x-amz-access-token': access_token,
      'x-amz-date': isoDate,
      'Authorization': 'AWS4-HMAC-SHA256 Credential=' + ACCESS_ID + '/' + credential_scope + ', SignedHeaders=' + signedheaders + ', Signature=' + signature,
    }
  }
  const orders = UrlFetchApp.fetch(end_point + canonicalURI + canonicalQueryString, options);
  console.log(orders);
}

　
上記のように２つに分けた場合は、①単独では動かず、②の copy.js を複製して使用することを想定しています。
（冒頭に記載したコードは、①と②を合体したものですので、単一のファイルだけで動くはずです）

②で認証・認可が必要になる場面で ①を呼び出して認証・認可に必要な処理を肩代わりさせます。
この過程でアクセストークンを ①の中に保管しておきます。

実際に②がいろいろな処理を行う場面でアクセストークンが必要になった場合は、getToken()によって①からアクセストークンを取得する、という考え方です。

---

追記

他の人にも協力してもらい、いろいろ試しましたが、このスクリプトは下記のような根本的な問題点があるらしいことが分かりました。

• ①originalを所有(作成)しているGoogleアカウント以外のアカウントが、コピーしたファイルから showDialog を実行した場合、認可フローを完了させることができない（トークンが無効または期限が切れていると表示される）

（①[オリジナル]を所有（作成）しているGoogleアカウントであれば ②[コピー]のshowDialogを実行しても問題なく認証フローを完了できる）
これは、オリジナルとコピー両方公開ファイルにしても変わりません。
（おそらくGASまたはOAuth2.0の仕組み上不可避と思われます）

一方、一部ではうまく行っています。

• ①[オリジナル]での認証・認可後、オリジナルを所有（作成）しているアカウント以外のアカウントが ②[コピー]を利用して①[オリジナル]からアクセストークンを受け取り、アクセストークンを利用した処理を行うことは可能。
• ①からもらったアクセストークンが揮発した場合でも、①から自動的に更新後のアクセストークンを取得できる。

　
したがって、少なくとも最初の認証・認可フローは①を所有しているアカウント（①を作成したアカウント）で行う必要がありそうです。

　

　

追記２

結局、運用方針としては、下記のように①と②を分離し、

• ①は開発者／管理者が専有してメンテナンス（最初だけ認証・認可を行ってリフレッシュトークン・アクセストークンをキャッシュしておく）
• 利用者側には②をコピーして使ってもらう（①がアクセストークンを保持している限り②側での認証・認可フローは不要）

というのが現実的かもしれませんね。

crient_secret が書かれたファイルをむやみに渡す必要がなくなるというメリットもあると思います。

　
①改（認証・認可用ファイル。showDialogを元に戻した）。デプロイし、デプロイＵＲＬを②改に記載する。

AUTH_ENDPOINT = 'https://XXX';
TOKEN_ENDPOINT = 'https://YYY';
CLIENT_ID = 'AAA';
CLIENT_SECRET = 'BBB';
APP_ID = 'CCC';

// OAuth2ライブラリ使用
function getService() {
　略
    .setLock(LockService.getUserLock());
}

function authCallback(request) {
　略
}

function doGet(e) {
  if (e.parameter.authmode)
    return toJson({ authorizationUrl: getService.getAuthorizationUrl() })

  if (getService.hasAccess())
    return toJson({ authorized: true, token: getService.getAccessToken() })

  return toJson({ authorized: false })
}

function toJson(content) {
　略
}

/**
 * 認証用ダイアログ（html）表示
 * セラーセントラルの認証URLへリンクさせる
 */
function showDialog(){
  const service = getService();
  const url = service.getAuthorizationUrl();
  const tag_text = `<button type="button" class="btn btn-primary" onclick="window.open('${url}')">セラーセントラルで認証する</button>`;
  const html = HtmlService.createHtmlOutput(tag_text);
  SpreadsheetApp.getUi().showModalDialog(html, "認証ダイアログ");
}

②改
実際の処理を行うファイル。こちらを複製してセラーにつかってもらう。
利用者セラーは認証・認可フローを行わない前提のため、showDialogは①へ移動した。
こちらは特にデプロイする必要はない。

const DEPLOY_URL = 'https://script.google.com/macros/s/***/exec';  // ①のデプロイURL

/**
 * アクセストークンを取得する。
 */
function getToken() {
  const respjson = UrlFetchApp.fetch(DEPLOY_URL).getContentText();
  const response = JSON.parse(respjson);
  if (response.authorized) {
    return response.token;
  } else {
    return "UNAUTHORIZED"
  }
}

/*個別処理を行う場合に必要となるアクセストークンは、getToken() で取得する。
 * 下記は注文を取得する例。
*/
function getOrders(){
  const access_token = getToken(); // アクセストークンの取得
  if (access_token==='UNAUTHORIZED) {
    console.log('認証が完了していないためアクセストークンを取得できません。' + 
      管理者に連絡して、認証・認可ファイルで再認証を行ってもらってください。');
  }
  略

  const end_point = 'https://sellingpartnerapi-eu.amazon.com';
　略
  const options = {
    'method': 'GET',
    'headers': {
      'x-amz-access-token': access_token,
      'x-amz-date': isoDate,
      'Authorization': 'AWS4-HMAC-SHA256 Credential=' + ACCESS_ID + '/' + credential_scope + ', SignedHeaders=' + signedheaders + ', Signature=' + signature,
    }
  }
  const orders = UrlFetchApp.fetch(end_point + canonicalURI + canonicalQueryString, options);
  console.log(orders);
}

　
ただし、現状の単純なコードでは、DEPLOY_URLを第三者に知られてしまうと、その人がアクセストークンを取得して勝手にいろいろできてしまうので、何らかの管理のしくみ（GET時のパラメータに特別なトークンが埋め込まれていないとアクセストークンを発行できないようにする等）を実装することが必要です。
（この点は冒頭に記載した単一ファイルを運用する場合でも同じです。さらに単一ファイルだと認証に必要なclient_id や client_secret まで利用者セラーに知られてしまうのが問題だと思います）

Comments

[thimone]

丁寧な説明に加え、実装と検証までしていただき、非常にありがたいです。
追記２について疑問点なのですが、
②改のスプレッドシートで認可フローを実行しないとしているため、
以下2つのどちらかの運用となるのかなと思っています。どちらでしょうか。
(1)①改で所有者のユーザが最初に認可フローを完了させる。
　　②改を利用する各ユーザは、①改で認可されたセラーアカウント1つのみ使用しAPIを利用する。
(2)所有者でないユーザでも、①改を（②を経由せず）直接実行すれば認可できる？
　　②改を利用する各ユーザは、①改を利用して各自セラーアカウントを認可し、
　　各自のセラーアカウントでAPIを利用する。

「専有」等書かれてますので(1)なのだろうと思っていますが、
気になっているのは利用者ごとに各自のセラーアカウントを利用してAPIを叩けるか、という点になります。

[qnoir]

後付けで申し訳ございませんが、上記は、Amazon SP-APIでの検証ではなく、他の一般的なOAuth2.0のアプリケーション（具体的にはBASE API)での検証になっています。（Amazon SP-APIの開発者アカウントや出品アカウントを持っていないため）
したがって、各自のセラーアカウントを利用してAPIを叩けるかについては、実際にやってみていただかないことにはわからないと思います。