Bedrudは複数の認証方式をサポートしています。

JWT (JSON Web Tokens)

Bedrudはセッション管理にJWTを使用しています。ログイン時に、サーバーは2つのトークンを返します:

1. Access Token: 短命（例: 1時間）。保護されたAPIエンドポイントへのアクセスに使用されます。
2. Refresh Token: 長命（例: 30日間）。再度ログインすることなく新しいAccess Tokenを取得するために使用されます。

これらのトークンの検証は、internal/middleware/auth.goファイルで行われます。

トークン管理とセキュリティ

1. トークンペア戦略（ローテーション）

Bedrudは安全なトークンローテーション戦略を採用しています。ユーザーが認証されると、以下のトークンが発行されます:

• Access Token: HS256で署名され、ユーザーID、名前、権限を含みます。短い期間有効です（tokenDurationで設定可能）。
• Refresh Token: 別の長命トークン。

ローテーション: Access Tokenの有効期限が切れると、クライアントはRefresh Tokenを/api/auth/refreshに送信します。サーバーは新しいペアのトークンを発行し、データベースに保存されているリフレッシュトークンを更新します。これにより、トークンが盗まれた場合でも脆弱な期間を限定できます。

2. トークンの失効（ブラックリスト化）

安全なログアウトをサポートするため、Bedrudはトークンブラックリストを実装しています。

• ユーザーがログアウトすると、現在のRefresh Tokenがblocked_refresh_tokensテーブルに追加されます。
• セッションを更新する前に、サーバーはこのテーブルを確認します。トークンがブロックされている場合、リクエストは直ちに拒否されます。
• バックグラウンドタスク（Scheduler）が、これらのブロックされたトークンの自然な有効期限後に自動的にクリーンアップするように設計されています。

3. JWT Claims構造

トークンは、バックエンドとフロントエンドがデータベースへのアクセスなしで迅速な判断を下せるようにするメタデータを保持しています:

{
  "userId": "uuid-string",
  "email": "user@example.com",
  "name": "Display Name",
  "accesses": ["user", "admin"],
  "exp": 123456789,
  "iat": 123456780
}

認証方式

1. ローカルメール・パスワード認証

• パスワードはbcryptでハッシュ化されます - プレーンテキストで保存されることはありません。
• 登録時に、データベースに新しいUserレコードが作成されます。

2. ソーシャルログイン (OAuth2)

BedrudはGothライブラリを使用して以下をサポートしています:

• Google
• GitHub
• Twitter

これらを有効にするには、config.yamlのauth:セクションにClient IDとAPI Secretを入力します。

3. パスキー (WebAuthn/FIDO2)

BedrudはFIDO2標準（WebAuthn）によるパスワードレス認証をサポートしています。

• 登録セレモニー:
  1. 開始: サーバーは暗号学的に安全なチャレンジを生成し、ユーザーのセッションに保存します。
  2. 完了: クライアントのオーセンティケーター（例: TouchID、YubiKey）がチャレンジに署名します。サーバーはアテステーションを検証し、公開鍵を抽出してpasskeysテーブルに保存します。
• 認証セレモニー:
  1. 開始: サーバーは新しいチャレンジを発行します。
  2. 完了: クライアントは秘密鍵でチャレンジに署名します。サーバーはデータベースから公開鍵を取得し、署名を検証してサインカウンターを確認します。
• セキュリティ: Counterフィールドの照合によりリプレイアタックを防ぎます。オーセンティケーターのカウンターが保存されたカウンター以上でない場合、ログインは拒否されます。

4. ゲストログイン

ユーザーが名前を入力するだけでミーティングに即座に参加できるようにします。サーバーはguestロールの一時的なユーザーレコードを作成します。

メール確認

設定で requireEmailVerification: true の場合、ローカル（OAuth以外）の登録とログインにはメール確認が必要です：

• 登録 はユーザーを作成しますが EmailVerifiedAt を nil に設定します。確認が完了するまでログインできません。
• ログイン は未確認アカウントに対して 403 と {"requiresVerification": true} を返します。
• 再送信 は POST /api/auth/verify/resend 経由 — verificationEmailCooldownMins と別のレート制限バケット（authResendMaxRequests）によって制限されます。
• 自動クリーンアップ は unverifiedAccountTTLHours（デフォルト48時間、0で無効）後に未確認アカウントを削除します。
• メールアドレス変更 は新しい確認フローをトリガーします。ユーザーはログインしたままになり、新しいトークンが発行されます。

ゲストユーザーは対象外です — メールアドレスを持ちません。

パスワードリセット

パスワードリセットフロー（SMTPが必要）：

1. POST /api/auth/forgot-password に {"email": "..."} — サーバーがメールにリセットリンクを送信
2. POST /api/auth/reset-password に {"token": "...", "newPassword": "..."} — 新しいパスワードを設定

リセットトークンのTTLは resetTokenTTLHours（デフォルト1時間）で制御されます。forgot-password エンドポイントは認証レート制限バケットを共有します。

クールダウン & レート制限

Bedrudは4つの独立したレート制限バケットを使用します：

バケットを 0 に設定 = 無効。すべての制限はリモートIP単位です。超過したリクエストは 429 Too Many Requests と Retry-After ヘッダーを返します。

相互運用性とCORS

Bedrudは複数のオリジンからのアクセスが可能に設計されています。これは開発時（React開発サーバー）と本番環境（異なるサブドメイン）の両方で重要です。

• CORSポリシー: config.yamlで定義されます。OAuthおよびパスキーセレモニーで使用されるセッションクッキーに必要なAllowCredentials: trueをサポートしています。
• 許可されたオリジン: デフォルトでは、サーバー自身のドメインとlocalhost:3000（React開発サーバーのポート）を許可しています。

ユーザーロール（アクセス制御）

各ユーザーは accesses 配列を持ち、複数のアクセスレベルを同時に保持できます。JWTクレームには完全な accesses 配列が含まれ、ミドルウェアが詳細な権限チェックを行えます。

アクセスレベル

ロール階層

superadmin > admin > moderator > user > guest

superadmin はルームモデレーターとして昇格されていなくても、任意のルームで任意のモデレーション操作を実行できます。ルーム作成者は自動的にルーム管理者となり、参加者をモデレーターに昇格できます。

ロールの割り当て

ロールは複数のチャネルを通じて管理されます:

• CLI: bedrud user create（user として作成）、bedrud user promote（superadmin を追加）、bedrud user demote（superadmin を削除）
• 管理ダッシュボード: ユーザー詳細ページに昇格/降格ボタン
• 管理者API: PUT /api/admin/users/:id/accesses で希望する accesses 配列を指定
• 会議中: ルーム作成者が参加者をルームレベルのモデレーターに昇格可能

注意: 最初のsuperadminを作成するAPIエンドポイントやWeb UIはありません。インストール後、CLI（bedrud user create + bedrud user promote）を使用して初回管理者アクセスをブートストラップする必要があります。これは意図的なセキュリティ対策です。