Authleteで実現したMCP対応可能な認証・認可基盤

参考になった

会員限定コンテンツです。無料登録すると制限なしでお読みいただけます。

無料登録してアーキテクチャを見る

レビュー投稿日の情報になります

株式会社Finswer / Doppon

メンバー / フルスタックエンジニア・プロダクトエンジニア / 従業員規模: 11名〜50名 / エンジニア組織: 10名以下

最終更新日2026/06/23投稿日2026/06/24

利用プラン

利用機能

ツールの利用規模

ツールの利用開始時期

事業形態

Business (マネージドクラウド)

認証認可

11名〜50名

2026年6月

B to B

B to C

利用プラン	Business (マネージドクラウド)
利用機能	認証認可
ツールの利用規模	11名〜50名
ツールの利用開始時期	2026年6月
事業形態	B to B B to C

アーキテクチャ

会員限定コンテンツ無料登録してアーキテクチャを見る

導入の背景・解決したかった問題

導入背景

ツール導入前の課題

事業戦略上、パートナー企業に公開する外部APIの認証・認可基盤の整備が必要になっていた。
外部APIだけでなく、最近注目されているリモートMCPサーバーのホスティングも視野に入れており、認証・認可基盤がカバーすべき範囲は当初想定より広がっていた。
- さらにリモートMCPサーバーのチャネルではOAuth 2.1/OIDCへの準拠は前提だった。
一方で、チャネルごとにトークン発行の仕組みを個別に作り込むのは開発・保守の両面で負担が大きく、フィンテック事業として求められるセキュリティ水準を自前実装で維持し続けることにはリスクがあると考えていた。

どのような状態を目指していたか

パートナー企業とのAPI連携や、AIエージェント経由(MCP)の利用といった多様な外部チャネルに対して、ユーザーのデータを安全に開放できるプラットフォームになっている状態。
あわせて、事業の成長に伴ってパートナーやトラフィックが増えても、コスト・パフォーマンスの両面で認可基盤がボトルネックにならないこと、そして将来FAPI準拠が求められた場合にも無理なく拡張できることを重視していた。

比較検討したサービス

Auth0
- 世界中で利用実績があり、国内だと経済産業省(GビズID)でも採用実績があり。
- ログインUI・ユーザーDB・認可サーバーまでをフルマネージドで提供。
- Ref:
  - https://auth0.com
  - https://auth0.com/resources/whitepapers/meti-case-study-jp
Ory Hydra / Ory Kratos
- ChatGPTを提供するOpenAIでも採用実績あり。
- Go製のOSS認証・認可コンポーネント群(セルフホスト可、SaaS版は Ory Network)。
- Hydra:
  - OpenID Certified™ の OAuth 2.0 / OpenID Connect プロバイダー。
  - ログインUIやユーザー管理を持たないヘッドレス構成で、既存のID基盤と接続可能。
- Kratos:
  - APIベースのアイデンティティ・ユーザー管理システム。
  - ログイン/登録、MFA、アカウントリカバリー、プロフィール管理などのセルフサービスフローを提供。
- 両者を組み合わせると Auth0 相当のフルスタック構成を自前で構築できる。
- Ref:

選定理由

料金体系
- Authlete は当社のユースケースにおいては実質的に OAuthクライアントベースでの課金体系になっていた。
- Auth0 は月間アクティブユーザーベースでの課金体系になっていた。
- Authlete の方が将来に渡ってコストコントロールがしやすかった。
- Ref:
  - https://www.authlete.com/ja/pricing
  - https://auth0.com/jp/pricing
これまでの実績
- Authlete では日本のフィンテック領域でも採用実績があった。
- 例) みんなの銀行・セブン銀行・ auじぶん銀行・北國銀行
- Ref:
  - https://www.authlete.com/ja/resources/videos-jp/20231212-03
  - https://www.authlete.com/ja/news-jp/20241203-hokkokubank

導入の成果

どのような成果が得られたか

設計段階で想定していた課題を解決できただけでなく、比較的短期間で認証・認可基盤を立ち上げられた。

トークン発行や署名鍵(JWKS)の管理、仕様の追従といった、認可サーバーを自前で実装・セルフホストする場合に必要となる作業の多くを Authlete側に委ねられたため、構築の手間を大きく削減できた。

また、導入にあたって Authleteに技術的な観点も含めて相談できたことで、設計の手戻りを抑えながら導入コストを下げ、見通しのよいアーキテクチャで構築を進められた点も、自前実装では得にくいメリットだと感じている。

導入時の苦労・悩み

要件定義・設計と技術選定をほぼ並行で進める必要があったため、ツール選定の段階でどこまでの拡張性・柔軟性を見込んでおくか、の判断に悩んだ。現時点の要件だけでなく、将来のFAPI対応やチャネル追加まで見据えてどこに線を引くかが難しい論点だった。
クラウド型(マネージド)のサービスを採用する場合でも、OAuth 2.1 / OIDCに対する一定の理解は前提として必要だった。マネージドだからといって仕様を知らずに使えるわけではなく、たとえば認可フローのうちどこまでをサービス側が担い、どこからを自分たちで実装・運用する必要があるのか(ログインや同意画面、トークン発行の前後で自社が持つべき責務の範囲)を見極めるには、フロー全体の理解が求められた。
- とりわけリモートMCPサーバーへの対応の検討段階では、OAuth 2.1 のかなり新しい仕様まで踏み込んで理解しておく必要があった。
- Ref: https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization

導入に向けた社内への説明

上長・チームへの説明

他のマネージドサービスではなくAuthleteを選んだ理由として、次の2点を説明した。

リモートMCPサーバーのホスティングに必要な仕様への対応状況という観点で、Authleteが他社より先行していた点
課金体系の観点で、月間アクティブユーザーベースよりも実質的にOAuthクライアントベースの方が、将来にわたってコストコントロールがしやすい点

そのうえで、セルフホスティングではなくマネージドサービスを選んだ理由として、次の2点を説明した。

リモートMCPサーバーに併せて認可サーバーをセルフホスティングする場合、進化の速いMCP・認可まわりの仕様にエンジニア側が継続的に追従する必要があり、その開発・保守コストが負担になるリスクがある点
将来FAPI対応が必要になった場合、自前実装ではかなりの開発工数がかかると見込まれ、マネージドサービスを選ぶ方が確実だと考えられる点

活用方法

よく使う機能

OAuth 2.1 / OIDCの仕様判断をAuthleteに任せられるため、自社側の実装はリクエストの受け渡しと、Authleteが返すアクションに応じた応答に集中できる。実際に常用しているのは次の機能だ。

Authlete API	用途	対応する自社エンドポイント
認可エンドポイント (Process Authorization Request API)	認可リクエストの検証・解析。返却されるアクション(INTERACTION / LOCATION など)に従って画面遷移を制御する	`GET/POST /authorize`
認可コードの発行 (Issue Authorization Response API)	同意後の認可コード発行。subject(ユーザーID)とクレーム(JWTアクセストークン向けクレームを含む)を渡す	`POST /consent`(承認時)
認可失敗応答 (Fail Authorization Request API)	同意拒否時などに、仕様に沿った失敗応答を生成する	`POST /consent`(拒否時)
トークンエンドポイント (Process Token Request API)	認可コードをアクセストークンに交換する。クライアント認証の検証も委ねる	`POST /token`
サーバーメタデータの提供 (Get Service Configuration API)	ディスカバリ用メタデータを取得して返す。設定の単一情報源として扱える	`GET /.well-known/openid-configuration`
JWK Setの提供 (Get JWK Set API)	署名検証用の公開鍵(JWK Set)を取得して返す	`GET /jwks`
トークンのイントロスペクション (Process Introspection Request API)	外部APIに提示されたアクセストークンの有効性(失効・スコープ・有効期限など)を問い合わせて検証する	外部APIのリソースサーバー

ツールの良い点

ドキュメントが手厚い点:
- 日本語のドキュメントも充実しており、仕様の解説だけでなくハンズオン形式の資料も揃っているため、導入時に参照しやすい。
最新仕様への対応が早い点:
- FAPI要件への準拠をはじめ、OAuthの最新仕様への追従が早い。
利用実績があり安心感がある点:
- 国内外での採用実績があり、安心して採用できる。
コストをコントロールしやすい点:
- 課金体系がOAuthクライアントベースで、利用規模の拡大に対して費用をコントロールしやすい。

ツールの課題点

料金体系での課題点:
- Freeプランの次のプランとの間に価格差があり、小規模に始める段階から本格利用へ移行する際の費用設計は事前に検討しておきたい。
SDKの課題点:
- 複数プログラミング言語向けにSDKが提供されているが、Javaベースのものが最も成熟している印象で、言語によって対応状況や成熟度に差がある可能性がある。

ツールを検討されている方へ

Authleteは、認可フローにおける最新仕様への追従が手厚い点に加え、データレジデンシー要件によってデータの取り扱いを国内に閉じておきたいユースケースにも対応できる点が強みだと感じました(AuthleteのクラウドサービスはリージョンをJP(日本)に指定できる)。

料金体系や柔軟性、国内での利用実績を踏まえると、マネージドサービスで認証・認可基盤をこれから構築しようとする企業にとって、検討する価値は十分にあると思います。