Prompt
(あそっか、Bashすら入ってないんだね…)
ところで、“Sign in with Google”のように、googleアカウントを利用してサインインする仕組みは、どのような手順で実装して利用するの？
そっか、そうだよね！Bashすら入ってないんだから、どうやって操作するんだって話になるよね。その気づき、鋭い！👍
さて、「Sign in with Google」の仕組みだね。これは「OAuth 2.0」という認証プロトコルと、「OpenID Connect (OIDC)」という認証レイヤーを組み合わせたものなんだ。
ユーザーのパスワードを預かることなく、安全に認証を行うための、モダンなWebサービスでは必須の技術だよ。
実装手順の概要
流れをざっくり説明すると、以下のステップを踏むことになる。
-
Google Developers Console での登録:
-
まず、Google Developers Console（またはGoogle Cloud Platform）で、自分のWebサービスを登録する。
-
すると、そのサービスを識別するための「クライアントID」と「クライアントシークレット」という鍵が発行される。
-
-
ユーザーの認証リクエスト:
-
ユーザーがWebサイトの「Sign in with Google」ボタンをクリックする。
-
Webサイトのフロントエンド（JavaScript）は、Googleの認証サーバーに認証リクエストを送る。このとき、クライアントIDや、認証が完了した後に戻ってくるURL（リダイレクトURI）を一緒に渡す。
-
-
ユーザーの許可:
-
Googleの認証サーバーが、ユーザーに「このWebサイトがあなたのGoogleアカウントへのアクセスを求めています」という許可画面を表示する。
-
ユーザーがアクセスを許可すると、GoogleはリダイレクトURIに「認可コード (Authorization Code)」を付けて、ユーザーをWebサイトに戻す。
-
-
アクセストークンの取得:
-
Webサイトのバックエンドサーバーが、この「認可コード」と、事前に発行された「クライアントシークレット」を使って、Googleの認証サーバーにリクエストを送る。
-
Googleは、このリクエストが正当なものだと確認できたら、「アクセストークン (Access Token)」と「IDトークン (ID Token)」をWebサイトのバックエンドに発行する。
-
-
ユーザー情報の取得とセッション管理:
-
IDトークンには、ユーザーIDやメールアドレスなどの情報が含まれている（JWTという形式で署名されている）。
-
バックエンドサーバーは、IDトークンを検証してユーザー情報を取得し、そのユーザーを自分のデータベースに登録したり、ログイン状態（セッション）を管理したりする。
-
役割分担の整理
君が今まで話してきたフロントエンドとバックエンドの分離の考え方、ここでも大活躍するんだ！
-
フロントエンド: ユーザーをGoogleの認証サーバーにリダイレクトする役割。そして、Googleから返ってきた認可コードをバックエンドに渡す役割を担う。
-
バックエンド: クライアントシークレットを安全に保管し、Googleと直接やり取りしてアクセストークンとIDトークンを取得・検証する、一番重要な役割を担う。
クライアントシークレットは、絶対にフロントエンドのJavaScriptには置いちゃダメだ。もし公開されたら、誰でも君のサービスになりすましてGoogleにアクセスできるようになってしまうからね。
OpenID Connect とは？
特に重要なのは、IDトークンの存在。
-
OAuth 2.0: もともとは「このアプリに、あなたのGoogleドライブのファイルへのアクセスを許可しますか？」といった、認可のためのプロトコルだった。
-
OpenID Connect: OAuth 2.0を拡張して、認証（ユーザーが誰かを識別する）のためのレイヤーを追加したもの。IDトークンという情報をやり取りすることで、認証を安全に行えるようになった。
「Sign in with Google」は、このOAuth 2.0とOpenID Connectを組み合わせた認証フローなんだ。ちょっと複雑だけど、この仕組みのおかげで、君が色々なWebサービスでGoogleアカウントを使って安全にログインできるってわけ！😉