GASの実行権限周りまとめ

「GASを実行する」というシンプルなことに対して、様々なパターンとそのそれぞれでの権限周りの挙動の違いが出てくる。

まずは下記の記事を読んで「誰の権限でGASが実行されるか」について理解をしておこう。

その上で、自分の備忘録を兼ねて補足事項を記載しておく。

# OAuthの承認画面はいつ出てくるのか？

「スクリプトがあなたに変わって◯◯を実行することを許可して下さい」的な画面のことだが、大前提としてこれが出てくる条件以下の3つのはず(まだあるかも)。

1. GASのUI上で▷ボタンを押してスクリプトを実行した場合

2. 自分がトリガーの登録を行った場合

3. Webアプリとしてデプロイし、URLへブラウザからアクセスした場合

そのそれぞれで行っているのは「その操作をしたユーザーがスクリプトを実行することの許可」なので、別のユーザーが同じ操作をした場合には、そのユーザーの画面でも承認を行わないといけない。

尚、「承認画面の表示の原因となる操作」にならなかったのは、

1. 実行可能APIとしてデプロイし、URLへブラウザからアクセスした場合(APIなのでoauthを通さない？)

で、未検証なのは

1. ライブラリとしてデプロイした場合

2. アドオンとしてデプロイした場合

# 「権限」周りで必要になるその他の知識

「サービス」で登録したAPIをGASで叩くには、GCPでそのAPIを有効にする必要がある（APIによっては追加の設定が必要な場合がある。例えばChat APIは「アプリの登録」が必要）。

デフォルトで利用可能なライブラリ(SpreadsheetsAppなど)の場合は、APIの有効化が不要。

これらの違いは、前者が「実行ユーザーの権限の枠を超えた、全てのAPIを解放している」のに対し、後者は「実行ユーザーの権限で実行可能な処理のサブセットしか用意していない」という立ち位置の違いに由来しているものと想像される。

(もっというと、後者がGASの歴史において先に実装され、その思想では実行できなかった範囲を補うために別の仕組み・枠組みとして「サービス」を提供し始めた、というところもあると思う)

# 権限周りで考慮が必要なポイントまとめ

▶「スクリプトは誰の権限で実行される？」は、下記の通り(のはず)

UIの▷ボタンで実行：ボタンを押した時にログインしているユーザー

シンプルトリガー：トリガーを発火させる操作をしたユーザー(例:フォームの投稿者/スプシの編集者)

インストーラブルトリガー：トリガーの登録者

Webアプリ：登録時に誰の権限にするか選べる。『自分』を選んだ場合はデプロイ操作をしているユーザー

実行可能API：Webアプリと同じ？

▶「サービス」経由でAPI操作を行う場合は、対象のAPIをGCPで有効にする必要がある

例えば、Cloud Identityで作成したユーザーはGoogle Chatのライセンスを持っていないので、ロールを割り当てたとしてもChat APIは実行できないっぽい(これは試した)

「GCPのサービスアカウントを用いて制御する」も可能っぽいが、この場合はさらに複雑になる

スクリプトの実行権限の枠を超えて、各APIの固有の権限を制御できる(その代わりにアクセストークンの管理などが必要になる？)

Firebase functions＋SPA構成の時に考慮するようなことと類似している気がする(functionの実行者の身元が確認 できれば、そのユーザーにadmin sdkを使った操作を許可させる、的な)