Googleログインの実装手順｜設定から会員との紐づけ、つまずきやすい5つの箇所

手間がかかるのは、コードより設定と設計

Googleログインは、Google Cloud での準備、画面への組み込み、会員データとの接続という順に進めます。時間を取られるのは、コードを書く作業よりも、その前後の設定と設計です。

1. 事前準備として、Google Cloud でプロジェクトを作り、認証情報を発行する
2. 実装では、ログインボタンを置き、返ってきた情報を受け取る
3. 会員データとの接続では、既存会員との名寄せと、新規会員の作り方を決める

3番目を後回しにすると、作り直しになります。会員データとの接続は、コードを書き始める前に決めておきましょう。

Googleログインの実装手順

上の3つを、実際の作業の順に並べ直すと次のようになります。ここでは、サーバー側で認可コードを受け取る一般的な方式（OAuth 2.0 / OpenID Connect の認可コードフロー）を例にしています。Google Cloud の設定画面での詳しい操作や、One Tap の組み込み方は「Googleログインの導入方法」で説明しています。

Google Cloud で OAuth クライアントを作る

Google Cloud でプロジェクトを作り、OAuth 同意画面を設定したうえで、種類を「ウェブ アプリケーション」にして OAuth クライアント ID を作成します。このとき、認証後に戻ってくるURL（承認済みのリダイレクトURI）も登録します。作成すると、クライアント ID とクライアントシークレットが発行されます。クライアントシークレットはサーバーだけに置き、ブラウザ側のコードには含めないでください。リダイレクトURIの登録で食い違いやすい箇所は、次の節で挙げています。

「Googleでログイン」ボタンを置く

ボタンを押したユーザーを、Google の認可画面へ送ります。送るときには、クライアント ID、リダイレクトURI、response_type=code、取得したい情報の範囲（scope。通常は openid email profile）、それに state を付けます。state は、戻ってきたリクエストが自分のサイトから始まったものかを確かめるための値で、なりすましを防ぐ役割があります。ボタンの見た目は、Google が定めるブランドガイドラインに合わせる必要があります。

認可コードを受け取り、トークンに交換する

ユーザーが同意すると、リダイレクトURIに認可コードが付いて戻ってきます。まず state が送ったときの値と一致するかを確かめ、それからサーバーから Google のトークンエンドポイントへ、認可コードとクライアントシークレットを送ります。返ってくるのが、IDトークンとアクセストークンです。

IDトークンを検証する

IDトークンには、ユーザーのソーシャルID（sub）やメールアドレスが入っています。中身を使う前に、Google が公開している鍵で署名を確かめ、aud が自分のクライアント ID と一致すること、iss が Google（accounts.google.com または https://accounts.google.com）であること、exp の有効期限が切れていないことを確認しましょう。Google が提供しているライブラリを使えば、これらの確認をまとめて行えます。

会員と紐づける

検証を通ったIDトークンの sub を使って、自社の会員データを探します。見つかればその会員としてログインさせ、見つからなければ新規登録か、既存会員との連携に進みます。この部分の設計が、以下で挙げる失敗のうち3つにかかわってきます。

事前準備で決めること

リダイレクトURIを確定させる

認証後にユーザーを戻すURLを、Google側に登録します。登録したURLと実際のURLが1文字でも違うと、エラーになります。

よく食い違うのは、次のような箇所です。

• 末尾のスラッシュの有無
• http と https の違い
• www の有無
• ステージング環境のURLの登録漏れ

登録は環境ごとに必要です。開発・ステージング・本番の3つを最初にまとめて登録しておけば、あとから直す手間が減ります。

取得する情報の範囲を決める

基本はメールアドレス・氏名・プロフィール画像とし、必要のない情報までは要求しないようにしましょう。同意画面に並ぶ項目が増えるほど、ユーザーは警戒します。

つまずきやすい5つの箇所

1. メールアドレスで会員を識別してしまう

設計でよくある失敗がこれです。メールアドレスはユーザーが変更できるため、識別子に使うと、変更された時点で別人として扱われ、同じ人の会員データが二重にできてしまいます。

会員の識別にはGoogleが発行するソーシャルID（sub）を使い、メールアドレスは連絡先として保持しておけば十分です。

2. 確認済みフラグを見ていない

取得したメールアドレスには、確認済みかどうかを示す情報（email_verified）が付いてきます。これを見ずにアドレスを信用すると、他人のアドレスで登録される余地が残るため、登録の処理で必ず確認してください。

3. 既存会員との名寄せを決めていない

すでに会員がいるサービスでは、Googleログインで入ってきた人が既存会員かどうかを判定しなければなりません。判定のやり方には、主に次の2通りがあります。

• メールアドレスで自動的に突き合わせる。手間はかからないが、誤って別人を紐づける危険がある
• 「既存の会員IDと連携しますか」と確認する連携画面を挟む。安全だが、ユーザーの操作が1手間増える

会員情報の重要度が高いサービスなら、連携画面を挟む方法をおすすめします。

4. ログインできなくなる場合に備えていない

Googleアカウントが削除されると、そのユーザーはそのままではログインできなくなります。代わりのログイン手段は最初から用意しておきましょう。既存会員が増えてからでは、足すのが難しくなります。

5. テスト環境のまま公開してしまう

Google Cloud の OAuth 同意画面には公開ステータスの設定があり、「テスト」のままだと、登録したテストユーザー以外はログインできません。公開の前に、公開ステータスが「本番環境」になっているかを確認しておきましょう。

実装後に確認すること

見落とされやすいのはアプリ内ブラウザです。SNSの投稿から来たユーザーは、通常のブラウザではなくアプリ内ブラウザでページを開きます。そこでログインが動かなければ、その経路から来るユーザーをまとめて逃すことになります。

2つ目のSNSを足すときに判断が変わる

Googleログイン1つだけなら、自社で実装するのも現実的です。事情が変わるのは、2つ目以降のSNSを足すときです。

• SNSごとに認証の仕様が違うため、実装はそのたびに必要になる
• 各SNSが仕様を変更するたびに、追随する担当者が必要になる
• 取得できる情報の形が違うため、会員データへの取り込み処理もそれぞれ必要になる

いまはGoogleだけでも、将来LINEを足す予定があるなら、最初から共通化しておくほうが結果的に安く済みます。

よくある質問

Googleログインの実装にクライアントシークレットは必要ですか

サーバー側で認可コードをトークンに交換する方式では必要です。クライアントシークレットはサーバーだけで保管し、ブラウザやアプリのコードには含めないでください。

「Googleでログイン」ボタンと One Tap はどう違いますか

ボタンは、ユーザーが押してから Google の画面に移ってログインする方式です。One Tap は、ページ上に表示されるGoogleアカウントの候補を選ぶだけでログインできる方式です。どちらも最後はIDトークンを受け取り、sub で会員と紐づける点は同じです。組み込み方は「Googleログインの導入方法」で説明しています。

自分はログインできるのに、ほかの人がログインできないのはなぜですか

OAuth 同意画面の公開ステータスが「テスト」のままになっている可能性があります。テストの状態では、登録したテストユーザーしかログインできません。公開ステータスを「本番環境」にしてから公開してください。

Login Plus について

Login Plusは、Googleを含む6つのIDプロバイダとパスキーに、1つの実装で対応できるサービスです。上で挙げた負担のうち、仕様変更への追随と、取得できる情報の形の違いは、Login Plus側で吸収します。

• Googleへの申請手順書を無償で提供
• 複数のSNSを1つの会員IDに紐づけ可能
• One Tapに対応