こんにちは、認証チームの @a2ikm です。
この記事では、 スタディサプリに「Google でログイン」機能を導入する際に行った OAuth App Verification について紹介します。
OAuth App Verification とは
先日、学校でスタディサプリを利用されているユーザに向けて Apple、Google、Microsoftのアカウントを利用してログインする機能がリリースされました。
このうち Google と Microsoft には、アプリの提供者を確認してもらう制度があります。 Google のこの制度は OAuth App Verification と呼ばれていて、確認を受けることで次のようなメリットがあります。
- ログイン画面や同意画面にアプリ名とアイコンが表示される（未確認の場合にはドメイン名のみが表示される）
- 機密（sensitive）と制限つき（restricted）に分類される scope *1 を利用することができるようになる
今回リリースした Google アカウントでログインする機能も、この OAuth App Verification の審査を受けて確認してもらいました。その結果、次のスクリーンショットのように、アプリ名とアイコンが表示されるようになりました。
大まかな流れ
まず、 OAuth App Verification の大まかな流れとしては次のようになっています。
- Google Cloud コンソールで、審査に必要な設問に回答する
- Google Cloud プロジェクトの Owner もしくは Editor がドメインを所有していることを Site ownership verification を通して確認してもらう
- 審査を申し込み、必要に応じて審査担当者とやり取りをしたのち、審査完了
なお、アプリが利用する scope によって設問や担当者とのやりとりが増える場合があります。それは、機密（sensitive）と制限つき（restricted）に分類される scope を利用する場合です。その場合、該当する scope を利用するユースケースを撮影したデモ動画や、文章での必要性の説明などが追加で求められます。
今回リリースしたログイン機能ではそれらに該当する scope を利用しなかったため、基本的な審査内容（brand-verification と呼ばれます）のみとなりました。この記事でもその範囲についてのみ扱います。
Step 1. 設問への回答
ここでは brand-verification に関する各設問について、スタディサプリがどのような回答を行ったか、どのような点に注意したかを記載します。
設問の内容は、 Google アカウントでログインする際のログイン画面や同意画面などにどのような内容を表示するかが主なものとなります。この入力画面は、 Google コンソール左上のハンバーガーメニューから "APIs & Services" > "OAuth consent screen" を開き、さらに左上のメニューから "Branding" メニューを開いたページとなります。
なお、審査要件に関する公式なドキュメントは OAuth App Verification Help Center 内の Verification requirements にあります。詳細な内容はそちらを参照してください。
アプリ名、ユーザーサポート用のメールアドレス、アイコン画像
まず最初の設問は、ユーザに向けて表示されるアプリ名（App name）とユーザーサポート用のメールアドレス、アイコン画像（App logo）です。これらは基本的に審査結果には影響しません。
スタディサプリでは次のスクリーンショットのように設定しています。
ホームページの URL
続いての設問は、アプリのホームページの URL です。この項目では次のようなことを注意する必要があります。
- リダイレクトを挟まない URL であること
- ホームページには後述するプライバシーポリシーと利用規約へのリンクが含まれていること、それらもリダイレクトを挟まない URL であること
スタディサプリでは次のスクリーンショットのように設定しています。
プライバシーポリシー、利用規約の URL
続いての設問は、アプリのプライバシーポリシーと利用規約の URL です。これらの項目では次のようなことを注意する必要があります。
- リダイレクトを挟まない URL であること
スタディサプリでは次のスクリーンショットのように設定しています。
Authorized domains
続いての設問は、 Authorized domains です。ここには次の URL で使われているドメイン名を入力します。
- ホームページ
- プライバシーポリシー
- 利用規約
- Authorized JavaScript origins と Authorized redirect URIs
- Web クライアントがある場合のみ
- 自動入力される
スタディサプリでは次のスクリーンショットのように設定しています。 （ひとつめは今回の Google ログインとは関係のない経緯で設定されている項目なので、モザイク処理をしています）
重要な点として、ここで入力するドメインはアプリ提供者が所有しているものだと Google に確認してもらう必要があります。確認の方法は Step 2 に記載します。
今回の例で言うと、先ほど入力したホームページの URL には learn.studysapuri.jp というドメインが使われているため、 learn.studysapuri.jp ドメインか、その親ドメインである studysapuri.jp ドメインのどちらかを入力することになります。スタディサプリの場合は親ドメインである studysapuri.jp ドメイン自体を所有し運用しているため、それを入力しました。これは、将来サブドメインの利用が増えたときにも何かと便利だろうという考えによるものです。
Developer contact information
最後の設問は、審査の担当者からアプリ開発者に連絡をするときのメールアドレスです。複数のメールアドレスを指定できます。これは審査結果には影響しません。
なお、審査の担当者からのメールは、この項目に追加したメールアドレスに加えて、 Google Cloud プロジェクトの Owner ロールと Editor ロールにも送信されます。
Step 2. Owner もしくは Editor による Site ownership verification
先ほど述べたように、 Authorized domains に入力したドメインはアプリ提供者が所有しているものだと Google に確認してもらう必要があります。具体的な手順は次のとおりです。
- Google Cloud プロジェクトに Owner もしくは Editor ロールを付与された開発者を用意する
- ロールの付与はユーザ単位とグループ単位のどちらでも良い
- 1で用意した開発者が、対象のドメインに対して Site ownership verification の手順を実施する
スタディサプリでは、変更の容易さや今後の運用などを踏まえて、次のように実施しました。
- 認証チーム全員を対象の Google Cloud プロジェクトに追加し、比較的権限の弱い Editor ロールを付与
- 認証チーム全員で、 DNS を使った方法 で Site ownership verification を実施
- Google Search Console に
studysapuri.jpを登録して、google-site-verification=XXXXXXXXと言う文字列を発行 - その文字列を
studysapuri.jpドメインの TXT レコードとして追加 - 再度 Google Search Console から
studysapuri.jpの確認処理を実行 - 1〜3を
recruit.co.jpドメインに対しても実施
- Google Search Console に
Site ownership verification が成功すると、 Google Search Console で次のような表示になります。
Step 3. 審査の申し込み〜審査担当者とのやり取り〜審査完了
以上の設定が完了したら、 Google Cloud コンソール左上のメニューから "Verification Center" メニューを開いて審査を申し込みます。
Verification Center には "PREPARE FOR VERIFICATION" というボタンが表示されます。これを押すと入力した内容の確認画面と、補足情報を入力するための "Additional Info" という入力欄が表示されます。
Additional Info には審査担当者に事前に伝えておきたい情報を記入します。例えば、スタディサプリの場合、サービスが studysapuri.jp ドメインで提供されているのに対して、プライバシーポリシーと利用規約は recruit.co.jp ドメインで提供されていています。この点について担当者に理解してもらうために、スタディサプリがリクルートによって運用されていること、当該のドキュメントはリクルートの他サービスと共用されていること、ただし文中にはスタディサプリへの言及があることなどを記入しました。*2
内容を確認したら "SUBMIT FOR VERIFICATION" を押して、審査が開始されます。
審査の経過はこの Verification Center とメールで通知されます。メールは次の宛先に届きます。
- Developer coontact information に設定したメールアドレス
- Google Cloud プロジェクトの Owner と Editor のメールアドレス
- ユーザーサポート用のメールアドレス
指摘事項を修正した後の再審査依頼など、審査担当者とのやりとりもそのメールで行うことになります。審査が完了した際にもメールでその旨が通知されます。
Tips
おまけとして、審査を進めるにあたって得られた Tips を共有します。
審査で困ったときに誰にサポートを求めれば良いか
審査担当者からのメールの指摘事項がなかなか理解できなかったりすることもあると思います。その場合、 ヘルプ を読むのも手ですが、それでも解決できない場合は審査担当者とのメールで質問をするのが良いようです。
審査担当者に問い合わせる際には次の2点に注意すると円滑なやり取りができるのかなと、経験的に感じています。
- 聞きたいことと自分たちがわかっていることを、ひとつのメールに集約させる。過去の会話で伝えたことであっても参照してもらえない可能性があるので、小分けにはしない
- スクリーンショットを添付するなどして、認識の齟齬を減らす
ちなみに、Google Cloud のサポートにも OAuth App Verification に関する質問をしてみたことがあります。しかし、そちらは別組織ということで回答できないか、回答できる内容であったとしても返答をもらうまでにとても時間がかかってしまいました。 OAuth App Verification の UI は Google Cloud コンソールにあるのですが、この点ややこしく、注意が必要です。
メールのやり取りをどのように開発チーム内で共有するか
チーム内での情報共有を考えると、審査担当者からのメールは漏れなく共有しておきたいところです。その方法として、チームの参加者が受け取れるメーリングリストを利用することが挙げられます。
メーリングリストで受信できるようにするには次のような設定方法があります。
- Developer contact information に設定する
- チームの所属するグループ単位で Owner もしくは Editor ロールを設定する
ところで、スタディサプリの運営組織ではフロー情報を Slack で、ストック情報を GitHub issue に集約しています。そのため、メールだとどうしても気づきにくくなってしまいます。
そこで認証チームでは、 Slack Integration を利用して、受信したメールを自分たちが普段見ているチャンネルに転送してくれるメールアドレスを発行し、それを Developer coontact information に設定しています。
ちなみにこの方法には嬉しい副作用があって、チャンネル上に転送されたメッセージには他の発言と同様に URL が割り振られます。そのため、開発者が個々に受け取ったメールと異なり、そのメッセージの URL を使ってメールを識別しながら会話をすることができるようになります。
最後に
この記事では、スタディサプリで Google ログインの OAuth App Verification の審査を受けた際に行ったことをまとめて紹介しました。なかなか困った時に具体的な事例を見つけにくいように思いますので、少しでも役に立てたら幸いです。
