OAuthとは？「Googleでサインイン」と委任アクセスの仕組み

OAuthは、ユーザーがあるアプリに、別のサービス上のアカウントへの限定的なアクセスを、パスワードを渡さずに許可できるようにするオープンな標準です。「Googleカレンダーに接続」をクリックして、「このアプリに予定の閲覧を許可しますか？」という画面が出てきたら、それがOAuthです。アプリが受け取るトークンは、あなたが承認した内容だけに対応しており、いつでも取り消せます。同じ仕組みに、OpenID Connectという追加の層を組み合わせると、「Googleでサインイン」などのボタンになります。

AIでアプリを作るときにOAuthが大切な理由

アプリを作るとき、OAuthは主に2つの場面で登場します。

1. ソーシャルログイン。 ユーザーに、新しいパスワードを作らせるのではなく、「Googleでサインイン」（またはApple、Microsoft、GitHub）を使ってほしい場合です。アプリにログインを追加する方法を参照してください。
2. ユーザーの他のサービスのアカウントへの接続。 アプリが、ユーザーのカレンダーを読んだり、ソーシャルアカウントに投稿したり、クラウドドライブのファイルを取得したり、会計データを同期したりする必要がある場合です。

どちらの場合も、AIビルダーがコードを書けますが、一部の手順はあなたにしかできません。たとえば、プロバイダーで開発者向けのアプリを作成すること、クライアントIDとクライアントシークレットを取得すること、コールバックURLを登録すること、そして一部の権限については、プロバイダーの審査を通すことです。OAuthの仕組みを知っておくと、これらの手順と、それによって起きるエラーが、ずっとわかりやすくなります。ログイン全体の概要は、認証とはを参照してください。

身近なたとえ

ホテルのキーカードを考えてみてください。チェックインのとき、フロントが本人確認をし、部屋とジムだけを開けられるカードを渡します。他の部屋やスタッフ専用エリアは開きません。カードには、パスポートの情報は入っていません。紛失した場合は、フロントがそのカードを無効にし、新しいカードを発行します。

• フロントは認可サーバー（Googleのサインインページ）にあたります。
• 本人確認は、あなたがGoogleにログインすることです。
• キーカードはアクセストークンにあたります。
• **「部屋とジムだけ」**は、あなたが承認したスコープです。
• チェックアウトは、トークンの期限切れ、またはあなたがアクセスを取り消すことにあたります。

あなたが使っているアプリは、あなたのGoogleのパスワードを見ることはなく、キーカードだけを見ます。

OAuthの仕組みをステップごとに

Webアプリで最も一般的な流れは、認可コードフローです。ユーザーが予定管理アプリにGoogleカレンダーを接続するときに起こることは、次のとおりです。

1. クリック。 ユーザーが「Googleカレンダーに接続」をクリックします。
2. プロバイダーへのリダイレクト。 アプリは、ブラウザをGoogleに送ります。その際、アプリのクライアントID、求めるスコープ（カレンダーの予定の読み取り）、Googleがユーザーを戻すべきリダイレクトURIを伝えます。
3. ログインと同意。 ユーザーがGoogleにサインインし（まだであれば）、アプリが求めている内容を一覧にした同意画面を見ます。「許可」をクリックします。
4. コードを持って戻る。 Googleが、短時間だけ有効な一度限りの認可コードとともに、ブラウザをアプリのリダイレクトURIに戻します。
5. サーバーで交換する。 アプリのサーバーが、そのコードとクライアントシークレットを直接Googleに送り、アクセストークン（多くの場合、リフレッシュトークンも）を受け取ります。
6. APIを使う。 サーバーがアクセストークンを使ってGoogleカレンダーのAPIを呼び出し、ユーザーの予定を取得します。

手順4のコールバックは、次のようなものです。

https://yourapp.com/auth/google/callback?code=4/0Adeu5B...&state=x7Kq9

手順5でのトークンのレスポンスは、次のようなJSONです。

{
  "access_token": "ya29.a0Af...",
  "expires_in": 3599,
  "refresh_token": "1//0gL...",
  "scope": "https://www.googleapis.com/auth/calendar.readonly",
  "token_type": "Bearer"
}

設計上の重要な点は、トークンの交換がサーバー間で行われることです。そのため、クライアントシークレットとトークンがブラウザを通過する必要はありません。

OAuth、OpenID Connect、自前のログインの比較

多くのアプリはこれらを組み合わせます。メールアドレスとパスワードによるログインに、OIDCによる「Googleでサインイン」を加え、さらに他のサービスへの個別のOAuth接続を持つ、という形です。

主な用語

よくある誤解

• 「OAuthはログインの仕組みだ」。 素のOAuthはアクセスを与えるものです。本人確認を担当するのはOpenID Connectです。アクセストークンを、誰であるかの証明としてそのまま使うと、実際にセキュリティ上のバグを生んだことがあります。
• 「アプリは私のパスワードを受け取る」。 そんなことはありません。それがポイントです。
• 「スコープを多く求めても無害」。 ユーザーは広範な要求を警戒します。また、Googleのようなプロバイダーは、機密性の高い、または制限されたスコープについてアプリの審査を求めることがあります。必要なものだけを求めてください。
• 「クライアントシークレットはフロントエンドに置いてよい」。 ブラウザのコードに入れたものは、すべて公開されます。サーバー側の秘密情報に保存してください。
• 「テストで動いたから、本番でも動く」。 プロバイダーは、審査前のアプリを制限することがよくあります（たとえば、登録されたテストユーザーだけ、など）。また、本番ドメインのリダイレクトURIは、別途登録する必要があります。
• 「トークンは永久に有効」。 アクセストークンはすぐに期限切れになり、ユーザーはアクセスを取り消せます。アプリは、その両方を適切に扱う必要があります。

AIビルダーに頼むこと

• 「OpenID Connectを使って『Googleでサインイン』を追加して。整備されたログイン用ライブラリを使い、OAuthの流れを自分で書かないで。」
• 「PKCEを併用した認可コードフローを使い、stateパラメーターを確認して。」
• 「クライアントIDとクライアントシークレットは、サーバー側の環境変数から読み込んで。」
• 「必要なスコープだけを求めて。カレンダーは読み取り専用にして。」
• 「プレビュー、公開URL、独自ドメインのそれぞれについて、プロバイダーのコンソールに登録すべきリダイレクトURLをすべて教えて。」
• 「リフレッシュトークンはデータベースに暗号化して保存して。期限切れまたは取り消されたトークンの場合は、ユーザーに再接続を求めて。」
• 「ユーザーが設定ページから連携を解除できるようにして。」

MythexとOAuth

Mythexには、作ったアプリのエンドユーザー向けの組み込みのログイン機能はありません。ドキュメントでは、自分で用意する方式が説明されています。認証ライブラリやホスト型のプロバイダーを選び、そのキーをプロジェクトの秘密情報として保存すると、エージェントがコードを書きます。このための開始用のプロンプトは、認証を追加するレシピにあります。また、Mythex自体でもOAuthに出会うことがあります。Googleでサインアップでき、リポジトリ同期のためのGitHub接続にはGitHubのOAuthを使い、MythexにMCPで接続するAIクライアントは、OAuthの同意ページを経由します。詳しくは、認証とはと二要素認証とはを参照してください。

よくある質問