WIC と CIC は何が違うのだろう?
Okta 社が Auth0 社を買収したのは2021年春。
それまで特定のプラットフォームに依存することなく Workforce Identity に強みを持っていた Okta と、これまたプラットフォーム独立で Customer Identity に強みを持っていた Auth0 が一緒になった。
2022年、Okta 社はこれまで旧 Okta 製品が担当し Workforce と読んでいた分野を WIC（Workforce Identity Cloud）、そして、旧 Auth0 製品が担当し CIAM と読んでいた分野を CIC（Customer Identity Cloud）と呼び、両者の棲み分けを明確にした。
IT ソリューションをお客様に提供していると、この WIC と CIC を混同しているのではないかと見受けられる場面に少なからず遭遇する。
それは特定サービスを探されているお客様のみならず、提案するソリューションベンダー側にしても同じことを感じることもある。
これは多分、両者とも認証認可という同じ技術領域を核としたプロダクトであり、中心となる機能に大きな違いがないことで、追加開発により例えば旧 Okta 製品で CIC を実現したり、旧 Auth0 で WIC を実現することも可能であり、混同しやすいためではないかと思われる。
従業員の ID 管理には WIC、顧客の ID 管理には CIC と言われることもあるが、その違いもイマイチ、ピンとこないことはないだろうか。
WIC（Workforce Identity Cloud）とは？
Okta のホームページには「従業員、請負業者、ビジネスパートナーのアプリを、アイデンティティを重視したセキュリティで保護します。」とある。主な特徴としてはシングルサインオンや MFA、ライフサイクル管理などがあげられている。
WIC はイメージが湧きやすい。
企業に勤めるユーザーは、日々さまざまなアプリケーションを利用しながら仕事をこなす。最近では多くの場合、SaaS などのウェブアプリケーションを利用することになる。こうした状況下での課題は例えば；
- それぞれのウェブアプリケーションを利用するためには、当然、ユーザー認証（ログイン）が必要。その認証情報（ユーザーID・パスワードなど）が盗まれると、他人がなりすましてアプリケーションを利用でき、見せてはいけない情報が漏洩してしまう。利用するアプリケーションごとに個別のクレデンシャル（ユーザーID・パスワードの組み合わせ）を持たせて認証することは当然可能だが、複雑なパスワードを、利用するすべてのアプリケーションごとに覚えることはもはや人間の域を超えている。結果、同じパスワードを使い回すことが当然のように行われ、セキュリティ上の問題になる
- 同時にアプリケーションを切り替えるごとに（同じユーザーID・パスワードだったとしても！）、再度ログインを求められることは苦痛
- アプリケーションによっては、より強固な二段階認証・二要素認証にてログインすることになるが、この方式もアプリケーションごとにまちまちなことが多く、苦痛がさらに広がる
などなど...
WIC は、こうした課題を持つ、主に企業内のユーザー向けにシングルサインオンを中核としたサービスを提供してくれる。
ユーザーは WIC のポータルに１度ログインさえすれば、そのポータルに一覧表示されているさまざまなアプリケーションを、再度別のクレデンシャルでログインすることなく安全に利用できる。
また、情報システム部など企業の IT 管理を実施する部署からすると、個別アプリケーション独自の認証方式に依存せずにユーザーを一元管理できることから、最初のログイン（ポータルへのログイン）を強固な二要素認証などでガードし、他の認証方法でそれぞれのアプリケーションを利用することを禁止することで、情報漏洩の危険性を排除することができたり、また、ユーザーの登録や削除、どのアプリケーションをどういった権限で利用することができるかなどのライフサイクル管理が容易となる。
WIC の主な利用者は企業内のユーザーや情報システム部などの管理部門であり、できるだけユーザーへの負担を少なく様々なアプリケーションを利用できるのと同時に、情報漏洩対策やライフサイクル管理を簡便に実現できるサービスと考えられる。
このことから WIC は、例えば、どれだけ多くのアプリケーションと容易に接続できるか、従業員とアプリケーション利用のライフサイクル管理がワークフローなどで簡単に実現できるか、といった機能が重要であり、それを小規模な事業所から、複数のIT管理部署が世界中に散在するような大規模なエンタープライズまで包括して恩恵を受けることができる ID 管理サービスと捉えることができる。
CIC（Customer Identity Cloud）とは？
一方、CIC について、Okta のホームページには「コンシューマーアプリと SaaS アプリを保護し、最適化されたデジタルエクスペリエンスを実現できます。」とある。主な特徴としてはユニバーサルログインやシングルサインオン、組織などだ。
これだけでは違いはいまいち分からない。WIC もひとつのログイン画面（ユニバーサルログイン的なもの？）でポータルにログインし、複数のアプリケーションを使うシングルサインオンサービスであり、IT管理部門のためのワークフローなどの管理機構がある。では両者の決定的な違いはどこにあるのだろう？
CIC の前身となる Auth0 のファウンダーであるユーへニオ・ペース氏は「世界中のすべての開発者にとって ID とアクセス管理をシンプルかつ安全にすることを目標に Auth0 を設立しました。」と言う。
ここに WIC との大きな違いが見て取れる。
すなわち、CIC は開発者にとってのプロダクトであり、企業内のユーザーや情報システム部向けのプロダクトではなかった（少なくとも初期のマーケットは違った）ということになる。
ここで言う開発者とは、インターネット上のウェブサービスやモバイルアプリの開発者を指すことは自明だ。
ウェブサービスやモバイルアプリの開発者にとって、認証認可は必ず組み込まないといけない重要な機能である。しかし、この認証認可の仕組みを 正しく 実装することはなかなかに困難だ。
例えば、インターネット黎明期の昔はユーザー名とパスワードをそのままデータベースの中に入れ、ログイン画面のフォームに入力されたユーザー名とパスワードがデータベースに保存されたデータと一致するかどうかで認証を行うという実装が平然と行われていた。これは、今では当然あり得ない。データベース管理者には他人のパスワードが見れてしまうし、また、データベースの中身が仮に漏洩してしまったらパスワードがそのまま漏洩することになってしまう。そのため、実装としてハッシュやソルトといった手法でパスワードをそのまま保存しないようにする。
パスワードだけではない。求められるセキュリティ要件が高度になるにつれ、実装もそれに追随しなくてはならない。しかも、パスワードの例にあるように、最新の攻撃手法を考えた上で正しく実装しないと思わぬセキュリティホールを産んでしまい、ゆえに提供サービスの信頼性に直結する事態となる。
現在のように高度化されたセキュリティ要件に対して全てを正しく実装するというのは並大抵の知識では難しいことは誰もが想像できる。
私も Topcoder というウェブサービスのプラットフォーム責任者をしていたとき、認証認可は悩みのタネだった。ウェブサービスは日々様々な攻撃に晒される。クローラーと思わしき世界中に散らばる多数のクライアントから一気に認証を叩こうとするものから、中には国家単位ではないかと思われるような巧妙な手口、規模での攻撃など様々だった。
また、認証認可はユーザーに対するサービスの直接的な価値ではないにも関わらず、間違えてはいけない最重要機能である、という点も課題であった。
攻撃を受けるほどにビジネス的には さほど価値がない 機能のために多くのリソースを割かなくてはならないのは悩みとなる。
結果、Topcoder は 2013年から Auth0 の採用を開始し、その機能と圧倒的な実装の容易さによって少なくとも認証認可の悩みは解決に向かった。
（詳細は、私が Topcoder 退職後に同社 CTO となった Dave Messinger 氏の記事が詳しい：https://auth0.com/case-studies/topcoder）
このように、CIC はウェブやモバイルなどのアプリケーション開発者が、最新のセキュリティ要件に即したサービスを提供するために利用するためのコンポーネントと捉えることができる。CIC を利用することでパスワードの管理や MFA などへの対応を正しく独自に実装する手間がなくなる。
また、WIC で見てきたように、自分達が開発したサービスを顧客である企業が利用する際に、企業側で管理するクレデンシャルでシングルサインオンさせることなどが容易に実現できる。
CIC の主な利用者はアプリケーションの開発者であり、最新のセキュリティ要件に沿ったアプリケーションを正しく作ることができるサービスと考えられる。
このことから CIC は、例えば、開発するアプリケーションにどれだけ簡単に認証認可機構を組み込むことができ、また、どれだけの多岐に渡るアプリケーションアーキテクチャをサポートできるか、といった点を重視している ID 管理サービスと言えるのではないだろうか。
まとめ
機能比較だけを見ると、WIC と CIC には大きな違いはないようにパッと見た目には思える。
だが、CIC には、ユーザーがログインして利用できるアプリケーションが並んだポータルなどの機能はない。同様に、WIC にはマルチテナント型（SaaS）アプリケーションを開発することを容易にする、Organizations などの機能はない。
従業員の ID 管理には WIC、顧客の ID 管理には CIC と言われるが、これは若干ミスリーディングで、様々なアプリケーションを利用する側が活用するサービスが WIC で、アプリケーションを開発する側が活用するサービスが CIC という言い方が私にはピンとくる。
両者は解決したいニーズがそもそも違い、ゆえに中核機能は技術的には同じでも、それぞれの機能が目指す方向性が異なる。当然ながら、WIC と CIC では導入プロセスや考慮しなくてはならない点も違うものとなる。
とくに CIC の場合、認証認可やそれに付随するユーザー・組織の管理方針は影響が広範囲に及ぶことから後から変更することがなかなかに困難で、アプリケーションを開発する側の視点で全体アーキテクチャの中でどのように CIC を活用するのかを捉えることが大切であり、ユーザー・組織の隔離モデルやマルチテナント型アプリケーションのアーキテクチャノウハウと言った知識が必要になってくると思われる。
上述したユーへニオ・ペース氏と先日会話した時、グローバルでは CIC へのニーズが急激に高まっているとのことだった。同様に、Okta 社のダイアモンドパートナーで、ID 管理に関連した IT サービスを展開するアメリカ BeyondID 社の CEO アルーン・シュレスタ氏も、これまでは WIC が主流だったが CIC が伸びてきていると言う。
これはすなわち、これまでは業務プロセス効率化などの流れから、いかにシームレスかつセキュアに従業員が各種アプリケーションを利用できるのか、という WIC の主戦場だった世界が一定の落ち着きを見せ、多くの企業は新しいデジタルサービス（アプリケーション）を作り、顧客へ提供していくという「攻めのDX」の中で CIC を求める流れが加速していると考えることもできる。
今後は、これまで以上に、新しいデジタルサービスが誕生するスピードが加速していく。その中でとくに ID 管理（CIC）は重要なコンポーネントとなるのであろう。
告知
TC3は、Gigコミュニティとの革新的なコラボレーションでとくにOkta/Auth0を活用したCIC分野でのご支援や、DataScience/AI分野でのご支援を強みとしている会社です。
TC3では『デジタル顧客接点トータルサービス』として、Oktaの導入からアプリケーション開発までをトータルでご支援しております。トライアルの段階から、どのようにIDaaS/CIAMを導入するかについてもサポートさせていただきますので、お気軽にお問い合わせください。
また、同時に積極的に採用も実施しています。ご興味ある方はぜひ弊社リクルートページをご覧ください。