Google APIからGoogle Workspaceのユーザーデータにアクセスする最適な認証方法 #Ruby

はじめに

本記事はモチベーションクラウドシリーズ Advent Calendar 2022の21日目になります。

リンクアンドモチベーションでソフトウェアエンジニアをしているnakagam3です。
最近業務の中でGoogle APIを利用する機会があったのですが、知識不足が故にかGoogle APIの認証周りを調べるのになかなか骨が折れました。今回は備忘も兼ねて調べたことをまとめてみます。

Google APIの認証方式が３種類ある

Google APIには現在３種類の認証方式が存在するそうです。

1. APIキー方式

事前に発行しておいたAPIキーという文字列を、APIリクエストに含めて送信することで認証する方式です。
手軽な方式ではありますが、今回利用したかったAPIは対応していませんでした。
これはAPIキー方式が他２つに比べてセキュアではなく、Google Maps Platform APIなど一般公開されているデータにアクセスする一部のAPIにしか適していないためだそうです。
ということで却下。

2. OAuthクライアントID方式

皆さんがお持ちのGoogleアカウントを使って認証します。その際にアカウント所有者本人に同意を求め、同意されたらアクセスを許可する、という方式です。
OAuth2.0で定義されている認可コードフローにあたります。

※OAuth 2.0 全フローの図解と動画から引用

ユーザーアカウントを使って認証できるため試しやすく、またユーザー認証が入るので非常にセキュアというメリットもあります。この方式で実現できなくもなかったのですが、今後の運用面を考えると以下2点がネックとなったため別の方式を検討することにしました。

初回認証時にアクセス要求に同意する画面操作が必要になる
認証後もaccess token/refresh tokenの管理が必要になり、有効期限が切れた場合に1のオペレーションが再度必要になる

3. サービスアカウント方式

サービスアカウントという専用のアカウントとして認証することで、ユーザーへの認証は行わずアプリが直接サーバーにアクセスを要求する方式です。
OAuth2.0で定義されているクライアント・クレデンシャルズフローにあたります。

※OAuth 2.0 全フローの図解と動画から引用

ユーザーへの認証が無いため、バッチ処理のようにサーバー間の通信のみで完結する場合にのみ推奨されるようです。そのため認証情報はより厳密な管理が必要となりますが、今回のケースではこちらが適しているようですので、こちらを採用することにしました。

設定方法

公式の手順を参考に発行できました。

Google Workspace 管理者ヘルプ - サービスアカウントの作成

Google Workspaceの制約

サービスアカウント方式を採用した場合、通常ならサービスアカウントに対して「ファイルを共有して」データ取得・更新をするのが標準的な使い方なのですが、今回のケースではGoogle Workspace内に存在するファイルを更新する必要がありました。

皆さんのGoogle Workspaceには「ドメイン外のユーザーへの共有制限」が設定されていることが多いかと思います。サービスアカウントのメールアドレスは<サービスアカウント名>@<プロジェクト名>.iam.gserviceaccount.comのようなドメインになるので、この制約によってファイルを共有することができません。

この問題を解決する手段として見つけたのが「ドメイン全体の委任」という設定でした。

ドメイン全体の委任

この設定は、Google Workspace管理者から「ドメイン内のユーザーに代わって」ユーザーデータにアクセスすることを許可する、というものです。

既に管理者から許可されているため、ドメイン内のユーザーデータにアクセスする際ユーザーの同意などは不要になります。また、許可する際にスコープを指定できるため、許可された範囲外のデータにはアクセスできないようにもできます。

私はAWSで言うAssume Roleを許可する設定だと認識しました。Assume RoleはClassmethodさんの記事が分かりやすい。

IAM ロールの PassRole と AssumeRole をもう二度と忘れないために絵を描いてみた

設定方法

実際に設定するにはGoogle Workspaceの管理者しか実施できないため私はやっていませんが、公式ヘルプに手順が載っていました。

Google Workspace 管理者ヘルプ - API アクセスをドメイン全体の委任で制御する

Ruby on Railsからサービスアカウント方式で認証する

ここまでで認証アカウントの準備ができたので、実際に認証できるか試してみましょう！

gemはこちらのgoogle-api-ruby-clientを利用しました。下記コマンドでインストールできます。

gem install google-api-client

認証に必要な情報は以下のコードで生成できます。
サービスアカウントを作った時にsecret.jsonがダウンロードできると思いますが、その中から必要な情報を環境変数にセットすることで読み込むこともできます。環境変数を使う方がシークレットをコードと分離できるため管理しやすいでしょう。

# 以下の環境変数から認証情報を取得して認証する
# "GOOGLE_CLIENT_ID",
# "GOOGLE_CLIENT_EMAIL",
# "GOOGLE_ACCOUNT_TYPE",
# "GOOGLE_PRIVATE_KEY"
credentials = Google::Auth::ServiceAccountCredentials.make_creds(scope: [
    Google::Apis::DriveV3::AUTH_DRIVE,
])

また、subフィールドに特定のアカウントを指定することで、指定したアカウントとしてAPI実行ができます。ここでGoogle Workspaceのユーザーを指定する時に「ドメイン全体の委任」が効いてくるんですね。

delegated_account = "hoge@hoge.com"
credentials.update!(sub: delegated_account)

生成したcredentialsは各サービスのauthorizationにセットすれば通信の際に認証されます。

drives_service = Google::Apis::DriveV3::DriveService.new
drives_service.authorization = credentials

下記メソッドを実行すると、マイドライブの情報が取得できる＝認証通った！ということなので完成です。

drives_service.get_about()

おわりに

公式のドキュメントなどあるのはあるのですが、この結論に辿り着くまでに時間がかかってしまいました。
ですが認証関係は安全にデータを扱うためにとても重要な知識です。
今後も良いプロダクトを作っていくために正しく理解できるようにしていきたいですね。