部員・管理者向けAPIにおける認証要件のNeoShowcaseAuth一本化と認可設計

[reiroop]

解決したい課題

現在の /admin などの部員や管理者しか使用しない参照系（管理系）エンドポイントにおいて、APIの認証および認可（ロール制御）の設計に以下の課題があります。

1. 認証の過剰な許容範囲: /admin, /invoices (GET), /checkout/sessions (GET) は一般のメール認証セッション（EmailVerifiedSession）によるアクセスも許容していますが、これらを参照するのは「traQアカウントを持つ特定の部員・管理者（会計責任者など）」に限定されるべきです。インフラレベルで身元が保証された Showcase 認証（NeoShowcaseAuth）のみに絞り込むことで、なりすましや不正アクセスのリスクを完全に排除すべきです。
2. 認可ロール（権限の細分化）の必要性: 各エンドポイントは必ずしも同一の権限を要求するとは限らず、例えば「会計担当（Accountant）のみ請求書一覧や決済一覧（GET）を許可する」「システム管理者（Admin）のみ管理者一覧（GET）を許可する」といったように、人やグループごとに異なるアクセス制御（認可ポリシー）を設けるべきです。

• ※ POST /invoices（請求書作成）については、一般会員自身のセルフサービス発行の目的や設計の是非を含めて複雑な議論が必要なため、本Issueのスコープからは意図的に除外します。

---

達成したい要件・仕様設計

API全体の認証セキュリティを最高水準に高め、かつ将来の権限細分化に対応できる柔軟な設計を実現するため、以下の要件を満たすリファクタリングを行います。

1. 参照系管理APIの認証を NeoShowcaseAuth のみに一本化

以下のエンドポイントについて、security 定義から EmailVerifiedSession を削除し、NeoShowcaseAuth（X-Forwarded-User ヘッダー必須）のみに絞り込みます。

• GET /invoices
• GET /checkout/sessions
• GET /admin

2. Goサーバーのバックエンド側でのロールベース認可（RBAC）の導入

• StripeのAPIキーを権限別に発行して振り分けるアプローチは、Stripeの仕様制限および秘密キー管理コストの観点から非推奨とします。Stripe APIキーは単一の「マスター秘密キー」を使用します。
• 誰がどのエンドポイントを操作できるか（例: Accountant ロールには請求書参照を許可、Admin ロールには管理者管理を許可）のきめ細かな認可制御（RBAC）は、Goサーバーのバックエンドビジネスロジック内で完結させます。

3. OpenAPIドキュメント上での認可ポリシーと 403 の明示

• 各エンドポイントの description に、その操作に必要とされる認可要件（例: 「サークルの会計責任者権限が必要です」）を注記として明示します。
• 認証は通っているが権限が不足しているユーザーがアクセスした場合に返る 403 Forbidden のレスポンス定義（$ref: '#/components/responses/Forbidden'）が正しく定義されていることを保証します。