「認証・認可は後で考えよう」が最大の手戻りになる理由

新規開発の立ち上がり期、こんな声を聞いたことはありませんか。「認証・認可は後でいい。まず画面を作ろう」。気持ちはわかります。でも、この判断が後からどれほど大きな代償を生むか、私自身、何度も経験しました。

認証・認可の設計は、プロジェクト初期に固めておかないと全ティアの手戻りになります。フロントエンド、APIゲートウェイ、バックエンドのすべてを作り直す羽目になる。今回は、その構造的な理由と、3つのOSSを組み合わせた先行設計パターンを整理します。

なぜ「後回し」にすると手戻りが最大になるのか

認証・認可の後付けがとりわけ厄介なのは、全ティアにまたがる横断的関心事だからです。

フロントエンドは「誰がログインしているか」を知らないと、表示するメニューも、呼び出すAPIも決められません。APIゲートウェイは認証済みトークンを検証して通過させる責務を持ちます。バックエンドは「このユーザーがこのリソースにアクセスしていいか」を判断する必要があります。

この3つが疎結合に設計されていないまま機能開発が進むと、どこかで「やっぱりここにも認証チェックが必要だった」「このAPIはロールによって返すデータを変えないといけない」という発見が次々に出てきます。そのたびに、すでに完成したコードに手を入れる。これが「全ティアの手戻り」の正体です。

3層に分けて、それぞれOSSに委ねる

では、どう設計すればいいか。私が実践しているのは、認証・セッション管理・認可を3つの層に明確に分離し、それぞれ専用OSSに責務を委ねるパターンです。

第1層: 認証 - Keycloak

「あなたは誰ですか？」を答えるのが認証の仕事です。

Keycloakは、OIDCプロバイダーとして機能し、ユーザーID・パスワードの検証、MFA、ソーシャルログイン、企業のActive Directory連携まで一手に引き受けます。社内SSOが既にある環境なら、Keycloakをそのフロントに置くか、既存IdPと連携させるだけで「誰が操作しているか」が確定します。もちろん利用できるIdPがあるのであれば、Keycloakを構築・運用する必要はありません。

ここで重要なのは、 フロントエンドはKeycloakを直接意識しない ことです。Keycloakとのやり取りは次の第2層（Kong）が引き受けます。フロントエンドから見える認証の窓口は、Kongひとつだけになります。

第2層: セッション管理 - Kong

「このトークンはまだ有効ですか？」を答えるのがセッション管理です。

Kongは、APIゲートウェイとして全リクエストの入口に立ち、JWTトークンを検証して有効期限・スコープを確認します。「セッションは30分間有効」という設定もKong側で管理します。バックエンドの各サービスは、Kongが通過させたリクエストだけを受け取ればいい。トークン検証ロジックをバックエンドに実装する必要がなくなります。

そして フロントエンドから見える認証窓口はKongひとつだけ になります。Kongに oidc プラグインを入れて設定するだけで、Keycloakへのリダイレクト、JWTの取得、セッションへの紐付けまですべてKongが担います。フロントエンドはKong経由のAPIを叩くだけでよく、Keycloakの存在を直接知る必要はありません。プラグイン設定だけで済むので、コードを書く量はほぼゼロです。

第3層: 認可 - OpenFGA

「このユーザーは、このリソースにアクセスしていいですか？」を答えるのが認可です。

OpenFGAは、Googleが大規模サービスの権限管理に使った設計思想（Zanzibar）を元にしたOSSの認可エンジンです。Googleドキュメントで「閲覧者」「編集者」を細かく管理しているような仕組みを、自分たちのシステムに持ち込めるイメージです。「ユーザーAは文書Bの閲覧者である」「グループXのメンバーはフォルダYの編集権を持つ」といった関係性をモデリングし、「このリソースに対してこの操作を許可するか」をAPIで問い合わせられます。

なぜOpenFGAが必要かというと、ロールベースアクセス制御（RBAC）だけでは実際の業務要件をカバーしきれないことが多いからです。「Aプロジェクトのメンバーだけが見られる」「課長は部下の申請を承認できる」──こうした関係性はロール単位では表現できません。OpenFGAを使うと、こうした「誰が誰のどのリソースに何の権限を持つか」を宣言的に定義できます。

OpenFGAを利用して認可を実装するのは、バックエンドです。バックエンドはKongから渡されたJWTを検証し、OpenFGAに権限確認を問い合わせる。フロントエンドでは、バックエンドで判断した結果を受けて、描画するメニューやボタンを出し分ける。これで、フロントエンドは認証・認可のロジックから解放されます。

初期に固めると、実装コストが劇的に下がる

この3層を最初期に設計すると何が起きるか。

フロントエンドが意識するのはKongだけです。Kong経由のAPIを叩く。認証が切れていればKongが自動的にKeycloakのログインページへ誘導してくれます。「ログイン中かどうか」もセッションクッキーの有無で判断できる。Keycloakも、その先にあるユーザーストアやMFAも、フロントエンドのコードからは見えません。

バックエンドは「Kongが通したリクエストだけ受け付ける → OpenFGAに権限確認を問い合わせる → 結果に応じてデータを返す」という構造になります。認証ロジックをサービスごとに実装する必要がない。

よく「認可ロジックが複雑化してきたらリファクタリングしよう」という話になりますが、最初からOpenFGAを使っていれば、リファクタリングの必要そのものがなくなります。権限の追加・変更がOpenFGAのモデル定義の変更だけで済み、アプリケーションコードに触れなくて済む。

「後でやればいい」が破綻するタイミング

実際に後回しにしたプロジェクトでは、こんな発見が起きます。

• 「ロール管理が必要になったが、現在のAPIがロール情報を持っていない」

• 「フロントエンドで権限チェックをしているが、APIも同じチェックをしないといけないことがわかった」

• 「管理者だけが見られる画面を作ろうとしたら、セッション管理の仕組みがなかった」

どれも、認証・認可が後付けになっていることによる発見です。そして気づいたときには、フロント・バックエンド・インフラ全体を整合させる大工事が必要になっています。

まず最初に決めること

認証・認可の先行設計として、私が最初期に固める判断ポイントをまとめます。

1. IdPを何にするか: Keycloakか、Active Directoryか、クラウドサービスか。社内SSOがあれば連携方法を確認する

2. APIゲートウェイを何にするか: KongかAmazon API Gatewayか、あるいはサービスメッシュか。JWTの検証をここに集約する

3. 認可モデルをどう定義するか: シンプルなRBACで足りるか、組織や役職の考慮が必要か。複雑になる予感があればOpenFGAを最初から採用する

この3つを最初期に決定するだけで、後からの手戻りが劇的に減ります。技術選定のコストは数日。後回しにしたときの手戻りは数週間から数ヶ月になりうる。どちらを選ぶかは明白です。

プロジェクト初期の「認証は後でいい」という声が聞こえたとき、その声は善意から来ています。でも、その判断が後でどれほど高くつくかを知っているなら、最初に少しの時間を投じて設計を固める価値は十分にあります。

技術的な詳細は以下の記事にまとめています。