Table of Contents
この文字起こしは、2024 年 12 月 11 日に開催された Authlete Customer and Partner Meetup 2024 のプレゼンテーションのひとつです。NRI セキュアテクノロジーズ株式会社 ID ソリューション事業部長 大島修氏に、自社のテクノロジーに Authlete を結合し、CIAM ソリューションの革新を実現した事例についてお話しいただきました。
我々は CIAM（コンシューマー向けの IAM）ソリューションを長年提供しており、その中で Authlete さんとお付き合いさせていただいています。今回のセッションでは、過去の経緯やノウハウに基づく Authlete 活用のポイントについて、みなさまに共有できればと思います。
NRI セキュアテクノロジーズ（NRI セキュア）の大島と申します。ID ソリューション事業部で ID 関連の事業の責任者をしています。その他、OpenID Foundation の Coporate Board や OpenID ファウンデーション・ジャパンの理事をさせていただいております。
NRI セキュアは野村総合研究所グループの中でサイバーセキュリティ分野に特化した企業です。セキュリティのコンサルティングサービスや DX セキュリティ、マネージドセキュリティサービス、ソフトウェアを提供しています。このうちソフトウェア事業において「Uni-ID」という ID ソリューションを展開しています。
CIAM とは Consumer Identity and Access Management、消費者向けの ID 基盤を意味します。消費者向けのデジタルサービスにおいて快適かつ安全・安心な顧客体験を提供するために、オンボーディングや認証、リソースのアクセス制御などのプロセスを担います。言ってみれば、あらゆる顧客接点を ID で仲介するハブとなるのが CIAM です。
我々が提供している Uni-ID Libra は、CIAM に必要なすべての機能をパッケージ化したソリューションです。赤枠で囲った「認可」の部分に Authlete を活用しています。
CIAM のソリューションとして国内シェアナンバーワンという評価をいただいています。顧客会員向けの ID 基盤として、さまざまなお客様にご活用いただいている実績があります。
当社は 2008 年から Uni-ID というブランドで認証・認可基盤を提供しておりました。OpenID や OAuth 2.0 に関しても、ドラフト仕様の段階から製品に取り込んでいました。OpenID Connect の仕様策定の中心にいた崎村さんが当時は NRI の社員として活動されていたこともあり、ID の標準技術を積極的に自社製品に採用してきました。
2016 年、新しい製品を作ろうというタイミングで Authlete の採用を決定しました。Authlete はまだ設立されたばかりのスタートアップで、実績もほとんどない状況でした。
当社自身でも標準仕様の準拠に積極的に取り組んでいたので、認可のコアのエンジンを自社開発するという選択肢もありました。我々は 2015 年の OpenID Connect Certification プログラムの開始時に世界で初めて認定を取った 6 社のうちの 1 社であり、認証・認可の標準仕様に準拠し実装できる技術力もあると自負していました。
新製品を検討し始めた 2016 年、Authlete のバージョンは 0.1 でした。しかし、Authlete はすでにその段階で OpenID Connect の全フロー・OAuth 2.0 の全グラントタイプに対応し、主要な拡張プロファイルもカバーしていました。このカバレッジの広さは非常に驚くべきポイントでした。当時そのようなカバレッジを持つ商用製品は ForgeRock の OpenAM のようなフル機能かつ重厚長大な IAM 製品しかありませんでした。
Authlete さんから提供いただいた API 仕様書の品質が非常に高く、各 API の仕様やエラーコードなどが明確・詳細に定義されていました。ドキュメントがしっかりしている製品は、中身もしっかりしているという印象を受けます。Authlete の場合も、製品の品質へのこだわりが、そういったドキュメントから垣間見えました。
創業者の川崎さんをはじめとする Authlete の開発メンバーの方々が、非常に高い専門性と、標準技術に厳格に準拠するという一貫したポリシーをお持ちでした。製品に関して、これはなぜこういう仕様なのかと質問すると、すぐに明確な回答がありました。その一貫性や標準準拠へのこだわりが非常に頼もしく、信頼がおけるなという印象を受けました。
また、我々からさまざまな意見や要望をあげさせていただく機会が多くありましたが、その内容に合理性があると判断いただければ、すぐに取り込んでもらえました。そのような柔軟性も大きなポイントでした。
CIAM には認証や ID 管理などいろいろな機能が必要ですが、広範囲な開発をすべて自分たちでやるのは大変です。とくに認証・認可周りの技術仕様は複雑であり、処理を正しくかつ網羅的に実装するには相当な量の開発・テストが必要になります。一方、素早く新製品をマーケットに投入することも求められました。Authlete はカバレッジも優れており、「時間を買う」という観点で非常に有力な選択肢でした。
認証・認可の世界は、ユースケースに特化したプロファイル定義や新しい標準技術がどんどん出てくる、非常にダイナミックな領域です。我々は自身に問いを立てました。「Authlete と同等以上の認可エンジンを、自分たちで将来に渡って拡張維持し続けられるのか?」と。この問いに対する答えは「否」です。このダイナミックな世界で、きちんと体制を作ってずっとやり続けるには、非常に大きなパワーがかかります。
企業は限られたリソースをどこに割り当てるべきか。当然、自分たちの強みや競争力を最も発揮できる領域にフォーカスしていくことになります。ほとんどの企業にとっては、認可機能そのものはビジネスの付加価値を生み出しません。付加価値を生み出すのはアプリケーションやサービスそのものです。
当社の場合、長年さまざまなお客さまに CIAM のソリューション提供や構築支援をしており、その競争力の源泉は、トータルパッケージとしての CIAM の提供、構築支援のプロフェッショナルサービス、セキュリティ実現のコンサルテーションです。よって、そこに我々の付加価値をフォーカスすべきと判断しました。
我々の製品にどうやって Authlete を組み込んでいくか、Authlete さんのメンバーと議論を重ねました。ここに貼っている写真は、ちょうど 8 年前の 2016 年の 12 月、Authlete さんが弊社に来られてディスカッションしたときのホワイトボードです。要件に対して、Authlete にどういった機能があって、それをどういう役割分担で、どう組み込めば製品として成立するのか、いろいろ議論を重ねました。そしてまずは机上で検討して、その次にプロトタイプを作ってフィージビリティーを検証、という流れで進めました。
その時点で我々はすでに、自社製の認可ライブラリを用いて新製品（Uni-ID Libra）の開発に着手していました。しかし認可部分を Authlete に切り替えて、1 ヶ月ほど検証し、最終的に Authlete の採用を判断しました。これは当時作っていたプロトタイプです。
Authlete で全てを賄えたかというと、そうではなかった部分があって、当時まだ機能的に全部は揃っていなかったところもありますし、我々自身が持つ要件でちょっと Authlete の機能では足りないところが一部ありました。そういったところは自前でカバーするという方針で製品を仕立てていきました。
万事がスムーズに行ったわけではありませんでした。Authlete さんの初期のバージョンは不具合も多く、我々の製品開発プロセスの中でかなりバグ出しをさせていただきました。また、実際のお客さまの環境に導入する中で見つかった、さまざまな不具合も直していただきました。そのように不具合はいろいろ出ましたが、指摘項目については迅速に修正していただきました。川崎さんが数時間後に修正パッチを送ってくれることもありました。
そのほか、製品開発やお客さまへの導入案件を通じていろいろな改善要望を出させていただき、柔軟に対応いただきました。ここに書いてあるところに関しても、Authlete 標準の機能として取り込んでいただくなど、非常に迅速かつ真摯にご対応いただきました。
ということで、今の Authlete の品質の一端は、我々が初期にいろいろ叩かせていただいたことで高まったところがあるんじゃないかなと、かなり貢献させていただいたかなと、自負しております。
我々のこれまでの経験から、Authlete を活用するにあたって留意すべきポイントを 8 つご紹介します。
開発の最も面倒な部分は Authlete さんに任せられるものの、認可サーバーとして実装しなくてはならない処理は多岐にわたります。たとえば state パラメーターや認証要求時の認証コンテクストのパラメーター（acr_values や max_age）と、認証サーバー側のセッションの有効期限、認証強度との整合性の確認や、認可パラメーターによる画面遷移の出しわけなどの考慮が必要です。あるいは UserInfo エンドポイントを実装する場合には、スコープに相当するクレームを ID のデータストアから取ってきて、それを使って UserInfo レスポンスを作って返す処理が発生します。
認証・認可サーバーの実装範囲は広く、汎用的な認可サーバーを追求し始めると際限が無くなります。まずは業務要件から認可サーバーとしてのミニマムな要件・要求仕様を抽出し、その範囲の実装にフォーカスするところをお勧めします。その上で、徐々にそれを拡張していく形で進めるのがいいかなと思っております。
OpenID Connect と OAuth のプロファイルのパラメーターやパターンはさまざまです。これらを理解が不十分なまま使うと思わぬ脆弱性・危険性を生む懸念があります。とくに Authlete は標準仕様をフルスペックでサポートしているので、わりと何でもできます。逆にそこが、気を抜くと危ないところです。
ですので、標準仕様の正しい理解が必要です。各パラメーターがどういう意味を持つのか、そのパラメーターを指定するとどういう意味を持つのかをきちんと理解した上で、接続のプロファイルを定義していくのがいいと思います。Authlete 自体はいろんなパラメーター・仕様に対応しており、後から拡張するのは比較的容易です。まずは自分たちの認可サーバーをミニマムから実装すると良いでしょう。もしわからないことがあったら、川崎さんのブログをご覧いただくとか、Authlete さんにどんどん聞いていただくのがいいんじゃないかなと思います。
さらに言うと、認証・認可基盤に接続するアプリケーションの開発者の方は、認証・認可にすごく詳しいわけではないので、そこに解釈の余地が生まれて、実装で失敗しちゃうところがあったりします。なので、アプリ開発者の方を迷わせないことが求められます。アプリ開発の方に解釈の余地を残さないような詳細な接続プロファイル/ガイドラインを定義・公開して、それに基づいて正しくつないでいただくことが、パラメーターのミスと仕様ミスを防ぐためには非常に重要です。
ということで、今の Authlete の品質の一端は、我々が初期にいろいろ叩かせていただいたことで高まったところがあるんじゃないかなと、かなり貢献させていただいたかなと、自負しております。
OpenID Connect や OAuth 自体は、標準化された仕様であり、かつ形式手法によるレビューを経て、仕様レベルで安全性が確保されています。ただし、たとえば認証サーバーと認可サーバーが分離しているアーキテクチャで、認可サーバーが認可リクエストを受け付けて、認可サーバーから認証サーバーにリダイレクトして、そこで ID / パスワードを入れて、認証サーバーから認可サーバーにリダイレクトで戻ってくるようなフローの場合、ブラウザー（ユーザーエージェント）を介在してリダイレクトする部分が結構危ないです。そこに攻撃のチャンスが生まれます。
認可サーバーと認証サーバーとの連携について、標準仕様ではない独自プロトコルを使って一時的なパラメーターをリダイレクトで引き回すパターンは、一般的だと思いますが、気をつけないと脆弱性が生じます。設計に十分な注意が必要ですし、できれば専門家のレビューを受けられた方がいいです。OpenID Connect を使っているから安全ということではないので注意しましょう。
Authlete 自体はオートスケールなどによる性能拡張が容易な作りになっています。我々のデプロイメントでは Amazon の ECS や Fargate を使った事例が多くありますが、こういった環境で動かすことでオートスケーリングによる性能拡張が非常に容易に行えるしくみになっています。
認可サーバーを設計・実装する際にも、いわゆる Twelve-Factor Appの ようなモダンな Web アプリケーションのベストプラクティスに沿った設計や、あるいはコンテナ環境での稼働を前提とした設計を意識してスケーラビリティを考慮すると良いと思います。
高可用性要件があるような案件、金融系などは該当するケースが多いと思いますが、DR 環境が必要という要件がある場合、構成として第一の選択肢になってくるのが、パイロットライト/ウォームスタンバイです。
たとえば東京がメインサイトで大阪が DR サイトのとき、大阪側で DB を常時リアルタイム同期し、何かあった時には大阪側に切り替えて業務を継続します。全てのサービスを常時上げておいてすぐに切り替えができるようにしておく戦略がウォームスタンバイ、データだけ同期しておいてサービスは切り替え時に立ち上げるのがパイロットライトです。
AWS を使う場合は、東京リージョンをメインサイトにして大阪を DR サイトにするケースが一般的かなと思います。たとえば、Amazon Aurora のグローバルデータベースクラスターを使って東京から大阪へのクロスリージョンレプリケーションを行っておきます。何かあった時には、東京から大阪へリージョン間フェイルオーバーをして、加えて Amazon Route 53 でトラフィックを東京から大阪に倒す（ルーティングする）かたちで DR するアーキテクチャです。
一方「マルチリージョンアクティブ/アクティブ」は、アプリケーション的にいろいろ制約が出てくるので現実にはちょっと厳しいです。Authlete でもマルチサイトで両系書き込みを実現しようとするといろんな考慮事項が発生するので、現実的には困難かなと思います。
Authlete がバージョンアップした際、API レスポンスの仕様が変わるケースがあります。ドキュメントに記載されてない粒度で、細かい範囲で変わることがあるので、注意しないと本番アプリケーションに影響してしまう可能性もあります。データベースの構成変更を伴うケースもあります。その場合、稼働した後に戻しますというのは、なかなか難しいこともあります。
ステージング環境などを使って、認可サーバーに接続するアプリケーションの動作検証も含めて、十分な期間を検証にあてる方が良いと思います。
Authlete ではキャッシュを使って高速なレスポンスを実現しています。そのキャッシュに Redis を使う場合において、もし認可サーバーも Redis を使うのであれば、そちらは Authlete とは別にしておいた方がいいです。
Authlete はデータの不整合や書き込みに失敗した際に Redis のキーを全部削除します。Authlete 単体で使っている Redis ならば、データベースからデータを確認できるので、動作上は問題ありません。しかし Redis を認可サーバーや他のアプリと共用している場合、database レベルで Redis 上でのデータ分離をしていたとしても、全てのキーを削除するので要注意です。Authlete 専用の Redis を用意して、他のアプリケーション共有しないことを原則にするといいと思います。
認可サーバーを実現しようとする時に、いくつか選択肢があります。左が、これはちょっとやらない方がいいんですがフルスクラッチ開発。真ん中が、Authlete をベースに足りない部分をスクラッチ開発。右が、たとえば我々の製品のようなフルスタックのソリューションの導入です。それぞれメリット・デメリットがあります。
真ん中の選択肢は、開発の柔軟性、要件の柔軟性、あと開発効率のバランスをうまく取れるのがメリットです。一方で、スクラッチ部分の開発保守体制を維持する必要がありますので、そのための知識があるメンバーを抱えていくことになります。たとえば自社に内製開発チームが存在し、自分たちでどんどん作れるよというような会社さんであれば、真ん中の選択肢がいいんじゃないかなと思います。
一方で、体制的にメンバーを抱えられない、専任体制は難しいっていう企業さんには、右側のフルスタックのソリューションを導入する選択肢があります。ただし製品パッケージなので、なんでもかんでもできるわけではなく、要件の柔軟性という意味では限界があります。
バランス、組織のニーズ、ケイパビリティを踏まえた選択を検討されるのが良いと思います。ちなみに一番左のスクラッチ開発は、基本的に悪手であり選択しないほうが良いです。
認可も含めたデジタルアイデンティティは、フィジカルな世界とサイバーの空間をつなげる、非常に重要なインフラです。物理的空間の我々をデジタルの世界に投影したのがデジタルアイデンティティであり、そこにいろんなデジタルサービスがつながっています。我々は日々の生活の中で、無意識にフィジカルとサイバーの空間を行き来しながら生活しています。
我々がお客様に導入しているソリューションも様々な業種で使用されていますし、認可の機能はユーザには見えない裏側の仕組みなので、見えないところで Authlete が使われているケースは、実は多いんじゃないかなと思います。Authlete は社会基盤として重要な役割を担うようになっています。
OpenID Connect や OAuth の仕様への準拠とスピードでは、Authlete は世界でも最も優れたレベルにあると認識しています。一方、認証・認可基盤として、金融サービスなど非常に重要な社会インフラで使われるケースもあります。後者においては、頻繁な機能拡張よりも、現在提供しているサービスを安定的・持続的に提供することが求められる側面もあります。プロダクトのライフサイクルとして、どんどん新しいものをキャッチアップしていく通常版と、安定版（Long Term Support 版）の、ハイブリッドなサポートモデルを検討いただけると非常にありがたいです。
弊社は CIAM ソリューションの提供だけではなく、認証認可認盤の設計レビューや方針のコンサルティング、セキュリティ診断も実施しております。何かございましたらお気軽にお問合わせいただければと考えております。
私の発表は以上です。どうもありがとうございました。
