現在広く普及している OAuth 2.0 (RFC 6749 および RFC 6750) は 2012 年に、OpenID Connect は 2014 年に策定された仕様です。先進的なサービス事業者では、仕様策定直後から、あるいは策定前のドラフト段階から、自社サービスに OAuth/OIDC を活用しています。その結果、自社だけではなく、パートナーやサプライヤー、そして一般の開発者を巻き込んだ API エコシステムの確立に成功しているケースも少なくありません。
一方、OAuth/OIDC の詳細仕様化（プロファイリング）のノウハウが十分存在していなかった、いわば「黎明期」から存在する環境では、古いままのプロファイルがいまでもそのまま手付かずとなっている状況が生まれています。たとえば、現在は利用が望ましいとされている PKCE が仕様化されたのは 2015 年ですが、それ以前に構築された OAuth/OIDC 基盤ではいまだに対応できていないこともあります。あるいは PKCE に対応している基盤であっても、コンフィデンシャルクライアントについては不要とするなど、現在のベストプラクティスに合わない運用を続けていることもあります。また、OAuth/OIDC のドラフト段階の仕様に準拠しているものの、パラメーター名や許容される書式の差異など、確定後の仕様との整合が取れていない状態も見受けられます。
古い OAuth/OIDC プロファイルを改善するためには、2 つのアプローチが考えられます。ひとつは、最新仕様を実装した OAuth/OIDC ソリューションを導入し、古いプロファイルを一新する、いわばビックバン・アプローチです。しかし通常、このやり方は現実的ではありません。現行の OAuth/OIDC 基盤が支える API エコシステムにはたくさんのクライアントが存在し、それらのクライアントに接続仕様を変更してもらうことは、技術的・ビジネス的に容易ではないからです。もうひとつのやり方は、既存環境と並列して新規 OAuth/OIDC 基盤を用意し、新たに追加されるクライアントをその別環境に収容する方法です。徐々に移行できるという利点はありますが、単純に言えば倍の運用工数がかかることになり、こちらも実際には難しいでしょう。
Authlete が提案するのは第三のアプローチです。これは、既存の OAuth/OIDC プロファイルを生かしたまま、最新の OAuth/OIDC 仕様を実装し、さらには将来の OAuth/OIDC の進化にも追随可能とする、OAuth/OIDC 基盤の「モダナイゼーション」です。
カギとなるのは、Authlete の特徴的なアーキテクチャである “OAuth/OIDC Component as a Service” です。サービス事業者は、OAuth/OIDC API のフロントエンドを自由に実装でき、同時に、プロトコル処理とトークン管理をすべて Authlete に移譲できます。これにより、既存 OAuth/OIDC プロファイルと最新仕様との差異を吸収し、スムーズな移行を実現します。
Authlete は最新の OAuth/OIDC 仕様に追随しているため、常に業界標準に準拠した OAuth/OIDC 基盤を構築可能
Authlete API を既存の基盤に組み込むことにより、現状の独自 OAuth/OIDC 仕様をそのまま許容しつつ、最新 OAuth/OIDC 標準仕様も処理できるように拡張可能
選択可能なアクセストークン形式や、きめ細かいトークン有効期間ポリシー設定などにより、既存 OAuth/OIDC 基盤の固有仕様を最大限に尊重したプロファイリングが可能
Authlete は共用クラウド、専有クラウド、オンプレミスパッケージの 3 通りのサービス体系を提供しており、メディア事業者はサービスの規模や特性に応じて利用形態を選択可能
