Jun 5, 2026

fosite vs Ory Hydra — コンテナ前提なら『OP セッションを書くか買うか』の一騎打ち

Lambda 前提を外して ECS でコンテナ化すると、fosite を不利にしていたステートフル化の難点が消え、Hydra も自然に動く。serverless 制約から解放された fosite vs Hydra を、サービス数・OP セッションの所有権・Cognito 連携・ロックインの観点で比較し、自社マルチプロダクトの自前 OIDC Provider にとっての解を出す。

OIDCSSOfositeHydraECS

前提 — 土俵を揃える

ここまで2本書いた。

  1. OIDC のセッションは3層あり、SSO = OP セッションを単一の権威として持つこと
  2. その OP セッションを誰が実装するか — 自作・fosite・Hydra

2本目で fosite と Hydra を比べたとき、判断を歪めていた要因が1つあった。**「Lambda 前提」**だ。fosite はストレージ必須なので Lambda だとステートフル化が重く、Hydra は常駐サーバなのでそもそも Lambda で動かない。この非対称が比較を曇らせていた。

そこで前提を変える。サービスをコンテナ化して ECS で動かす。すると:

つまり serverless 制約が外れ、fosite と Hydra が対等な土俵に乗る。この記事は、その上での一騎打ちだ。

ECS にして消えた差・残った差

論点Lambda 前提ECS 前提
fosite のストレージ必須△ DynamoDB 必須・往復増が懸念◎ RDS/Redis が普通。気にならない
Hydra の常駐サーバ✗ 動かない◎ ECS の定番用途
OP セッションの保存先DynamoDB 一択気味Postgres でも Redis でも自由
サービスの数—ここだけ差が残る

消えなかったのはただ1つ、サービスの数だ。これが ECS 後の本質的な分岐になる。

本質は2軸に圧縮される

土俵が揃った結果、fosite vs Hydra はこの2軸だけに圧縮される。

  1. 1サービス(fosite)か、2サービス + headless 連携(Hydra)か — 運用のシンプルさ
  2. OP セッションを書くか(fosite)、買うか(Hydra) — 制御 vs 既製

DB はどちらも要る(差は消えた)。Cognito 連携と login UI はどちらでも自作(共通資産)。残るのは上の2軸だけ。

fosite on ECS — 1サービス + DB

既存の自前 OIDC Provider をそのままコンテナ化し、自分で書いていたプロトコルの中身だけを fosite に差し替える。

ALB

OIDC サービス
1コンテナ

Cognito

RDS / Redis
セッション・コード・トークン

1つのコンテナの中に全部入る:

// fosite は「認証済みか」を判断しない。OP セッションは自前のまま。
sess := h.currentSession(c)            // ← 自作の OP セッション
if sess == nil { h.renderLogin(c); return }

ar, _ := provider.NewAuthorizeRequest(ctx, req)
oidcSession := &openid.DefaultSession{ /* sub, auth_time, claims */ }
resp, _ := provider.NewAuthorizeResponse(ctx, ar, oidcSession) // ← プロトコルは fosite
provider.WriteAuthorizeResponse(ctx, w, ar, resp)
評価
デプロイ単位1サービス。既存構造をそのまま育てられる
OP セッション自分で書く(全制御。トークン形式・セッション設計を握れる)
プロトコルの正しさ認定済みライブラリに移譲。自作の最大リスクが消える
ストレージRDS でも Redis でも DynamoDB でも自由(自分で Storage 実装)
学習コストStorage インターフェースが多く配線が多い。ドキュメント薄め

Hydra on ECS — 2サービス + DB

Hydra は ECS で自然に動く。ただし **headless(login/consent UI を持たない)**という性質は ECS にしても消えない。だから login/consent を別サービスに割る。

login_challenge でリダイレクト

accept: admin API

ブラウザ

ALB

Hydra public
コンテナ

login/consent provider
コンテナ

Cognito

Hydra admin
内部のみ

RDS Postgres 等
必須
評価
デプロイ単位2サービス(Hydra + login/consent provider)+ DB
OP セッション書かなくていい(Hydra が所有。SSO/consent/logout 込み)
プロトコルの正しさOIDC 認定をそのまま得る
ストレージリレーショナル DB 固定(Postgres 等)
学習コストlogin/consent provider の実装 + Hydra 運用の習得

OP セッションという「自前 OIDC で一番面倒な部分」を製品として買えるのが Hydra の価値。代償は2サービス運用と、Hydra の login/consent の流儀に乗ること。

ECS 前提での比較表

関心事fositeHydra
デプロイ単位1サービス + DB2サービス(Hydra + provider)+ DB
OP セッション(SSO)自分で書く(全制御)Hydra が所有(既製)
consent自分で書くHydra 管理(provider は自作)
logout / back-channel自分で書くHydra 提供
トークン形式の自由度◎ 自由△ Hydra の流儀
ストレージ選択◎ 自由(RDS/Redis/Dynamo)△ リレーショナル DB 固定
Cognito 連携・login UI自作(共通)自作(共通)
OIDC 認定自分で担保✅ 製品で担保
既存サービスの扱いそのまま育てるlogin provider に格下げ + Hydra 追加

どちらが勝つか

ユースケースで割れる。

fosite が勝つ:

Hydra が勝つ:

自社マルチプロダクトの自前 OIDC Provider という文脈だと、consent はほぼ素通しで third-party 開放も当面ない。この場合 Hydra の旨味(consent/logout/認定を買える)が出にくく、2サービス運用のコストだけが効いてくる。だから fosite が素直だ。

ロックインしない — Hydra の橋は焼けない

「fosite で始めると Hydra を捨てることになる」は誤解。両アプローチで必要になる login/consent provider(UI + Cognito 認証)は共通資産だから、後から載せ替えられる。

つまり fosite は「今の構造を活かす安い一手」かつ「後で Hydra に逃げられる」。最初から Hydra にすると、Lambda 由来の今の構造思想とズレた状態で2サービス運用を背負う。順序として fosite が先で損がない。

まとめ

← Back to all posts