AI生成アプリに認証を追加する方法

AIアプリビルダーはログイン画面を数秒でスキャフォールドできます。しかし、ユーザーをログインさせることは簡単な半分に過ぎません。難しい、セキュリティ上重要な半分は、認証された各ユーザーが自分のデータだけにアクセスできるようにすることです。このガイドでは、AI生成アプリに認証を正しく追加する方法を説明し、生成コードが陥りがちなポイントを指摘します。

認証と認可：違いを理解する

これらの2つの言葉は似ており、コード生成ツールも含めて常に混同されています。

• 認証 回答 "あなたは誰ですか?" これは本人確認を行います。正しいパスワード、有効なマジックリンク、Googleログインなど。
• 認可 回答 "あなたは何を許可されていますか?" これは、ログインユーザーがこの請求書を読んだり、そのレコードを編集したり、他のユーザーのアカウントを削除したりできるかどうかを決定します。

この記事で最も重要なパターンは次のとおりです。AIツールは認証を確実に実装しますが、認可を頻繁に失敗します。生成されたアプリはログインフォームを喜んで表示し、セッションを発行し、名前で挨拶しますが、それでもログインユーザーにフェッチさせます 誰かの URL内のIDを変更することによるデータ。その失敗モードを念頭に置いて進めよう。

認証方法を選択する

生成ツールのデフォルトではなく、ユーザーと脅威モデルに基づいて選択してください。

• メールとパスワード — なじみがあり自己完結型ですが、ハッシュ化、リセットフロー、侵害対応の負担はあなたにあります。
• マジックリンク — ユーザーにメール送信される一回限りの署名付きURL。漏洩するパスワードはありません。トレードオフはメールの到達性とリンクの短い有効期限です。
• OAuth / ソーシャルログイン — "Sign in with Google/GitHub" 資格情報の処理をプロバイダーに委任します。返されたメールとアカウントの状態を検証し、検証していないIDトークンは決して信頼しないでください。
• SSO (SAML / OIDC) — 中央管理を望むエンタープライズバイヤーに期待されます。通常は後から追加されますが、ユーザーモデルを設計して後で組み込めるようにしておきましょう。

複数の方法を提供しても問題ありません。ただし、パスワードでサインアップした後にGoogleを使用した人が二つのアカウントを持たないように、すべてが単一の正規ユーザーレコードに解決されるようにしてください。

セッション vs トークン

IDが確認されたら、リクエスト間でそれを記憶する必要があります。2つの主流なアプローチ：

1. サーバーセッション — サーバーはセッション状態を保存し、ブラウザに不透明なセッションIDをクッキーで渡します。失効が簡単：サーバー側のレコードを削除すればセッションは終了します。
2. ステートレストークン（JWT） — 署名付きトークンにはクレーム（ユーザーID、有効期限）が含まれます。サーバー側には何も保存されないため、スケーラビリティは高いですが、即時失効が難しくなります。漏洩した有効期限内のトークンは期限が切れるまで有効です。

ほとんどのメーカーやSaaSアプリでは、サーバーセッションまたはリフレッシュトークンと組み合わせた短命トークンの方が安全なデフォルトです。生成されたものが何であれ、実際に以下のことが可能であることを確認してください。 ユーザーをすべての場所からログアウトさせる そして侵害された認証情報を無効化する。

セキュアクッキーフラグは必須です

セッション識別子をどのように配信する場合でも、クッキーを正しく設定してください。生成されたコードではこれらが省略されることがよくあります：

• HttpOnly — JavaScriptがクッキーを読み取るのをブロックし、XSSによる盗難を制限します。
• Secure — クッキーはHTTPS経路でのみ送信されます。
• SameSite — Lax or Strict to reduce CSRF exposure.
• 適切な有効期限 そしてログイン時に新しいセッションIDを発行してセッション固定化を防止します。

Never put a JWT or session token in localStorage if you can use an HttpOnly cookie instead; storage that scripts can read is storage an XSS bug can steal.

パスワードを適切にハッシュ化する

パスワードを受け入れる場合は、低速でソルト付きのハッシュのみを保存してください。以下のような専用のパスワードハッシュアルゴリズムを使用します： bcrypt、scrypt、またはArgon2。パスワードにMD5、SHA-256、または高速な汎用ハッシュを使用しないでください。また、平文を決して保存しないでください。

• ライブラリにパスワードごとに一意のソルトを生成させてください。
• ライブラリの定数時間検証関数を使用して比較してください。
• 独自に考案するのではなく、公開されている現在のデフォルトのワークファクターに依存してください。

これは特に監査する価値があります。もっともらしく見える生成スニペットが静かに高速ハッシュを使用する可能性があるからです。生成された認証コードをレビューする際は、弱いハッシュをリリースブロッカーとして扱ってください。当社の AI生成アプリのセキュリティ監査ガイド では、これらのパターンを体系的にgrepする方法を解説しています。

脆弱性を作らないパスワードリセット

リセットフローは古典的な弱点です。防御的に構築しましょう：

• 生成する ランダムで単回使用のトークン アカウントに紐付け、そのハッシュのみを保存します。
• 与える 短い有効期限 （例：1時間）を使用後は無効化します。
• 返す 同じ応答 メールが存在するかどうかに関わらず、エンドポイントがアカウントの列挙に使用されないようにします。
• リセットリクエストをレート制限し、アカウントメールの変更などの機密変更には再認証を要求します。

ロールベースのアクセス制御

ほとんどのアプリは「ログインしているかどうか」だけでは不十分です。明示的なロールを定義します（例： admin, member, viewer）そして保護されたすべてのアクションに対してサーバー上でチェックします。この誠実さを保つための2つのルール：

• 認可を強制する場所は サーバー、UIでボタンを隠すだけでは不十分です。隠されたUIは便利さであり、制御ではありません。
• デフォルトは 拒否。新しいエンドポイントは、明示的にアクセスを許可するまでアクセス不可にすべきであり、誰かがロックするのを覚えるまで開いたままにしてはいけません。

明確なロール階層を持つもの（例： AIで構築されたCRM）を構築している場合は、エンドポイントを生成する前にロールをモデル化し、アクセスルールを後付けではなく組み込むようにしてください。

AIが通常スキップするステップ：オブジェクトレベルのアクセスをテストする

これはこの記事で最も重要なテストです。オブジェクトレベルの認可（欠けている場合はIDORと呼ばれることが多い）とは、以下をチェックすることを意味します： この ユーザーが所有またはアクセスできる この特定の レコードであり、単にログインしていることだけではありません。

直接テストする：

1. 2つのアカウントを作成します。ユーザーAとユーザーB。
2. ユーザーAとしてレコードを作成し、そのIDを記録します。
3. ユーザーBとしてログインし、APIを介して、およびURLを編集して、そのIDでユーザーAのレコードを要求します。
4. ユーザーBは403または404を受け取る必要があります。ユーザーAのデータは決して受け取らないこと。

読み取り、更新、削除の各操作をすべてのリソースタイプに対して繰り返します。生成されたコードは通常セッションをチェックしますが、クエリに所有権の条件を忘れるため、このシンプルな2アカウントテストで実際の脆弱性の多くを捕捉できます。これをあなたの AIアプリのデプロイ前チェックリストに組み込んでください.

まとめ

ビルダーにログイン画面と配線をスキャフォールディングさせましょう。それで実際に時間を節約できます。その後、リスクが集中する箇所に労力を割いてください：クッキーフラグ、パスワードハッシュ化、リセットトークンの衛生管理、ロールチェック、そして何よりもオブジェクトレベルのアクセスです。生成された出力を出荷可能かどうか検討している場合、私たちの見解は AI生成アプリが本番環境に対応しているかどうか および AIでSaaSのMVPを構築する この作業を文脈に位置づけます。

認証は、「クリックして通ると動作する」では不十分な数少ない領域の一つです。ハッピーパスだけでなく境界を検証すれば、生成された認証を自信を持って出荷できます。構築を始めますか？まずは LogicMint.