ユーザーは何でも接続できます。
あなたがトークンに触れることはありません。
4層構成のアイデンティティサービスと、エンドユーザーごとに暗号化された資格情報ブローカー。RS256 JWTはお客様側でJWKSを用いてローカルに検証し、あらゆる外部サービスへのOAuthフローはすべて弊社側で処理します。
ドキュメントを読むマルチテナントのアイデンティティとOAuth仲介は、週末で作れるものではありません。
階層ごとにスコープを分けるログイン体系、ネットワーク呼び出しなしに下流サービスが検証できるJWT、そしてユーザーが許可したあらゆる外部OAuthトークンを保管する場所が必要です——暗号化され、テナントごとに分離され、誰にも気づかれずに更新される場所が。Auth Managerがそのすべてを担うため、資格情報のロジックが二か所に分散することはありません。
4層構成のアイデンティティ
管理者 → 組織 → アプリケーション → ユーザー。各層は独自のID形式とログインモデルを持つため、権限が誤って上位層へエスカレートすることはありません。
ローカルで検証されるRS256 JWT
すべての下流サービスは公開されたJWKSエンドポイントに対して署名を検証します——ネットワークホップもリクエストごとの問い合わせも不要で、キー更新時には24時間の重複有効期間が設けられています。
資格情報ブローカー
接続されたあらゆる外部サービスへのエンドユーザーごとのOAuthトークンはテナントごとに分離されて管理され、お客様のサーバーにはスコープが限定されたJWTとしてのみ渡されます。
PKCEが強制されるOAuth
すべてのauthorization-codeフローは最初から最後までPKCEで保護され、パブリッククライアントやモバイルクライアントでも通常のOAuthが残す傍受の隙を塞ぎます。
保存時のエンベロープ暗号化
外部トークンはディスクに書き込まれる前にAES-256-GCMエンベロープ暗号化で包まれます——鍵を保持するのはブローカーのみで、お客様のアプリが持つことはありません。
Argon2idによるパスワードハッシュ化
プラットフォーム層および管理者の資格情報は、メモリハードネスに調整されたArgon2idでハッシュ化されます——多くの自作認証がいまだに使っている、GPUで容易に解読できる高速ハッシュではありません。
「接続」のクリックから、検証済みリクエストまで一つの流れで。
仲介ループ
開始 — ユーザーがアプリ内で「接続」をクリックすると、そのリクエストには階層(どのエンドユーザー、どの組織か)と対象の外部サービスが含まれます。
リダイレクト — Auth ManagerがPKCEで保護された認可URLを生成し、外部サービス自身のログイン・同意画面へリダイレクトします。
認可 — ユーザーは外部サービス自身の画面でアクセスを許可します——Auth Managerもお客様のアプリも、そのパスワードを見ることは決してありません。
交換 — 返却されたコードは検証済みのPKCE code_verifierとともにトークンへ交換されます。この過程でお客様のサーバーが関与することはありません。
暗号化と保存 — アクセストークンとリフレッシュトークンはAES-256-GCMエンベロープ暗号化で包まれ、そのエンドユーザー専用の分離されたレコードとして保存されます。
発行 — お客様のアプリはその接続に限定された、有効期限15分の短命なRS256 JWTを受け取ります——往復通信なしにJWKSでローカルに検証できます。
透過的な更新 — JWTの有効期限が近づく、または上流トークンの更新が必要になると、ブローカーは呼び出し元アプリを中断させることなく両方を更新します。
ログイン、アイデンティティ、トークン——すべてを一つのサーフェスで。
盗まれたリクエストが、盗まれたアイデンティティにならないように設計。
トークンがお客様のサーバーに届くことはありません — 外部OAuthトークンはブローカーの暗号化ストア内にのみ存在します。お客様が目にするのはスコープが限定されたJWTだけで、その裏にある資格情報が見えることはありません。
保存時のエンベロープ暗号化 — AES-256-GCM、テナントごとの鍵、保護対象データとは独立してローテーションされます。
Argon2idによるパスワードハッシュ化 — すべてのプラットフォーム層資格情報に対し、GPUによる解読に対抗するよう調整されたメモリハードなハッシュ化を適用します。
短命でローカル検証可能 — 15分間有効なRS256 JWTを往復通信なしにJWKSで確認します——漏えいしたトークンはすでに失効しているのと同じです。
PKCEが強制されるフロー — すべてのauthorization-code交換にはverifierが必要なため、リダイレクトが盗まれただけではログインは完了しません。
テナントおよび資格情報の分離 — 4層のスコープ管理により、ある組織のトークンが別の組織のリクエスト経路に入り込むことは決してなく、すべての発行が監査されます。
もはやお客様の問題ではなくなるアイデンティティの課題。
ユーザーがカレンダーを一度接続すると、6か月後もすべての呼び出しが正常に動作します——ブローカーがアプリに気づかれることなく何十回もトークンを更新しているからです。
管理者が一人のユーザーの接続を失効させると、そのユーザーの暗号化されたトークンは即座に破棄されますが、他のすべてのテナントの接続には影響がなく動作し続けます。
APIゲートウェイはキャッシュされたJWKSキーに対してリクエストのRS256署名をマイクロ秒単位で検証します——ホットパス上でAuth Managerへの呼び戻しは発生しません。
Auth Managerが署名鍵をローテーションしても、新旧両方の公開鍵はJWKS上で24時間有効なままとなるため、進行中のリクエストが壊れることはありません。
管理者、組織、アプリケーション、エンドユーザーはいずれも同じ4層構成の階層で認証を行い、理論上も実際の運用上も自分のスコープを超えて行動することはできません。
あなたのアイデンティティモデルをお持ちください。あとは私たちが仲介します。
4層のログインからユーザーごとのOAuth資格情報まで——Auth Managerが信頼境界のすべてを担うため、トークンがお客様のサーバーに留まることはありません。