アプリにログインを追加する方法：パスワード、マジックリンク、Google、ロール

アプリにログインを追加するには、方式を1つ選びます。メールとパスワード、マジックリンク（メールで送られる1回限りのサインインリンク）、または「Googleでログイン」です。そして、ゼロから作るのではなく、実績のある認証ライブラリかホスト型プロバイダーで実装します。次に、各種類の利用者ができることを決め（ロール）、すべてのページとAPIリクエストで、サーバー側でそれを強制します。セッションは安全なクッキーを使い、期限があり、ログアウト時に適切に終了するようにしてください。

このガイドでは、それぞれの選択肢と、動くログインと安全なログインを分ける細部を説明します。その背後にある概念については、認証とはを参照してください。

まず決める：そもそもログインが必要か？

ログインは手間と責任を増やします。次のような場合に必要です。

• 利用者が非公開のデータ（予約、文書、請求書）を持つ
• 利用者が、他の人が見るものを変更できる
• アクセスに料金を課す
• 立場によって権限が異なる（オーナー、スタッフ、顧客）

マーケティングサイト、公開のディレクトリ、メールを送るだけのフォームには、ログインは不要かもしれません。ウェイトリストにアカウントは不要で、メール欄があれば十分です。

よく使われる4つのログイン方式

2つを組み合わせるアプリも多くあります。Googleでのサインインとメールのマジックリンクの組み合わせは人気で、パスワードを一切保存せずに多くの人をカバーできます。

メールとパスワード

パスワードを提供するなら、次の点は必ず守ってください。

• 遅いパスワードハッシュのアルゴリズムでハッシュ化する。 OWASPのパスワード保管のガイダンスでは、Argon2idが推奨され、scrypt、bcrypt、PBKDF2が代替として挙げられています。平文で保存したり、高速な一般用のハッシュを使ったりしてはいけません。
• パスワードの再設定 は、ランダムで1回限りのリンクを使い、期限が切れるようにし、確認済みのメールアドレスに送ります。
• どのメールアドレスがアカウントを持つかを明かさない。 「入力されたメールアドレスが登録されていれば、再設定リンクを送信しました」の方が「アカウントが見つかりません」よりよいです。
• ログインと再設定の試行にレート制限をかけ、パスワードの推測を遅らせる。
• 長いパスワードとパスワードマネージャーを許可する。 変わった文字の組み合わせを強制するルールは使わないでください。

マジックリンクとワンタイムコード

マジックリンクは、利用者にメールで送られるサインインリンクです。クリックするとログインできます。ワンタイムコードは同じ考え方ですが、クリックではなく入力します。

• リンクとコードはすぐに期限切れになり、1回だけ使えるようにします。
• リンクは、クリックされた端末でログインさせるべきで、トークンがログやアナリティクスツールに残ってはいけません。
• 信頼できるメール送信が必要です。アプリからメールを送る方法を参照してください。GmailとOutlookでテストし、迷惑メールフォルダも確認してください。

Googleでログイン（およびその他のOAuthプロバイダー）

「Googleでログイン」はOAuthとOpenID Connectを使います。Googleが利用者が誰かを確認し、アプリにそのメールアドレスと名前を伝えます。2026年9月時点の設定は、Google Cloud ConsoleのGoogle Auth Platformセクションで行います。

1. プロジェクトを作成または選択し、ブランディングページを入力します。ここは、同意画面で利用者に表示される内容（アプリ名、サポート用メールアドレス、ロゴ）です。
2. クライアントページで、「Webアプリケーション」の種類のクライアントを作成します。
3. 承認済みのJavaScriptオリジンとリダイレクトURIを追加します。アプリが動いている正確なアドレスと、サインイン後にGoogleが利用者を戻す先のアドレスです。
4. クライアントIDとクライアントシークレットを、アプリのシークレットに保存します。

GoogleのOAuthドキュメントによると、よく起きる問題は次のとおりです。

• redirect_uri_mismatch：リダイレクトのアドレスは、httpとhttpsの違い、大文字と小文字、末尾のスラッシュを含め、完全に一致する必要があります。プレビュー用のアドレスと公開ドメインの両方を追加してください。
• HTTPSが必須：リダイレクトURIはHTTPSを使う必要があります。開発中のlocalhostは例外です。
• stateパラメーターは、戻ってきたときに確認して、クロスサイトのリクエストの偽造から守るべきです。優れたライブラリはこれを自動で行います。

基本的なログイン情報（名前、メール、プロフィール）だけを求める場合、Googleはアプリの検証は必須ではないとしています。利用者のGmail、Drive、カレンダーへのアクセスを求める場合は別で、検証が必要です。

自分で作るか、プロバイダーを使うか？

最初の2つはどちらも妥当です。ホスト型のプロバイダーは多くを代行しますが、依存関係が増え、アクティブユーザーごとに料金がかかることもあります。現在の料金は各サイトで確認してください。ライブラリはすべてを自分のデータベースに保持できますが、正しく設定すべき部分が増えます。どちらを選んでも、パスワードやセッションのロジックを手書きせず、そのライブラリを使うようAIに依頼してください。

ロールと権限

ログインは、誰かが誰かを教えてくれます。権限は、その人が何をできるかを決めます。最初は単純にしておきましょう。

ロールの名前より重要なルールは次のとおりです。

• 毎回、サーバーで確認する。 ページでボタンを隠しても、APIを直接呼び出す人を止めることはできません。
• 所有者で範囲を絞る。 会員が「予約123」を取得しようとしたら、それが自分のものである場合にだけ返すべきです。
• 利用者が自分で権限を上げられないようにする。 プロフィールの更新でブラウザから送られたロールのフィールドは無視してください。
• 初期値はアクセスなし。 新しいルートは、あなたがそうしないと決めない限り、ログインを必要とすべきです。

2つのアカウントでテストしてください。一方でログインし、レコードのIDを控えます。もう一方でログインし、そのレコードを開こうとしてみます。完全なテスト方法は、セキュリティチェックリストにあります。

セッションのセキュリティ

ログイン後、アプリはセッションによって利用者を記憶します。通常はクッキーです。OWASPのセッション管理のガイダンスでは、次が推奨されています。

• セッションクッキーにSecure（HTTPSのみ）、HttpOnly（ページのスクリプトから読めない）、SameSiteを設定する
• ログイン時に新しいセッションIDを発行し、権限が変わるときにも再度発行する
• アイドルタイムアウトと絶対的な最大有効期間を設け、サーバー側で強制する
• ログアウトは、クッキーを削除するだけでなく、サーバー上でセッションを終了させる
• 利用者がパスワードを変更したら、セッションを無効にする

ログイン用のトークンをブラウザのlocalStorageに保存する方法はチュートリアルでよく見られますが、ページで動くどのスクリプトにも見えてしまいます。Webアプリでは、安全なクッキーの方が通常はよいデフォルトです。

基本をカバーするプロンプト

このアプリにユーザーアカウントを追加して。利用者はメールとパスワード、またはGoogleでサインアップ、ログインできるようにして。独自の認証コードではなく、[ライブラリまたはプロバイダー]を使って。パスワードはArgon2idまたはbcryptでハッシュ化して。メールによるパスワード再設定を追加し、1時間で期限切れになる1回限りのリンクを使って。セッションは安全なHttpOnlyクッキーに保存して。/dashboardと、すべての/apiルートを保護し、ログインした利用者だけが使えるようにして。利用者が見られるのは自分のプロジェクトだけにして。すべてのユーザーを見られる「admin」ロールを追加して。/adminに入れるのは管理者だけにして、サーバーで確認して。

そのあとでテストします。サインアップ、ログアウト、ログイン、パスワードの再設定、ログアウト中に非公開のURLを試す、別の利用者のレコードを試す。

AIで作るログインのよくあるミス

• 保護がページの中だけにある。 ページはログアウト中の利用者をリダイレクトしますが、APIは誰にでもデータを返してしまいます。
• ブラウザ内のシークレット。 OAuthのクライアントシークレットや認証プロバイダーの管理キーは、サーバー側に置くべきものです。
• プレビューのURLと公開URLの取り違え。 Googleのリダイレクトなどが、プレビューを指したままになっていると、公開後にログインが壊れます。
• メールアドレスの確認がない。 誰でもanyone@company.comとしてサインアップできてしまいます。そのアドレスに紐付くものを与える前に、メールアドレスを確認してください。
• 正常系だけをテストする。 間違ったパスワード、期限切れのリンク、2つ目のアカウントも試してください。

Mythexでのログインの追加

Mythexでは、アプリの利用者のためのログインは、アプリに追加するものです。Mythexの自分のアカウントとは別物です。MythexにはログインのためのプロダクトはないのでAuthライブラリかプロバイダーとそのキーを持ち込みます。

1. 方式を選ぶ。例：自分のデータベースに保存するメールとパスワード、またはホスト型プロバイダーのSDK。
2. 利用者を自分で保存するなら、アプリにデータベースが必要です。チャットで依頼するか、/databaseを使ってください。
3. プロバイダーのキーをプロジェクトのシークレットに入れる（/secretsまたはプロジェクト設定）。
4. 上のようなプロンプトを使い、プレビューでテストする。Googleでログインする場合は、プレビューと公開アドレスの両方のリダイレクトURIを追加してください。

ドキュメントのアプリにログインを追加するも参照してください。有料の製品を作るなら、SaaSのMVPの作り方で、アカウントと請求をまとめて扱っています。

よくある質問