Okta（オクタ）とは？認証の仕組み・機能・料金・セキュリティを2026年版で解説

Okta（オクタ）は、社員や顧客のID（アカウント）をクラウド側で一元管理し、SaaSや社内システムへのログインを束ねるIDaaS（Identity as a Service）です。日本語では「オクタ」と読みます。ただ「SSOができるサービス」という説明だけでは、導入の可否は判断できません。実際に検討段階で問われるのは、認証がどう成立しているのか、いくらかかるのか、過去に大きなインシデントを起こしたベンダーを信用してよいのか、という3点です。この記事では、Okta社の一次情報（2026年1月期のForm 10-K、公式料金ページ、セキュリティアドバイザリ）をもとに、その3点を軸にOktaを整理します。

まとめ

• 正体：クラウド上のID基盤。2026年1月期のForm 10-Kと公式価格ページでは「Okta Platform」（従業員向け）と「Auth0 Platform」（顧客向け）の2構成に表記が置き換わっています（旧称のWorkforce Identity Cloudは一部の製品ページに残ります）。
• 認証の仕組み：SaaS側にパスワードを渡さず、SAML／OIDCの署名済みトークンで「この人は認証済み」と伝える方式。Okta FastPassを使えばデバイス内の秘密鍵で署名するパスワードレス認証になり、フィッシングで盗めるものが無くなります。
• 料金：2026年7月時点の公式ページはスイート制で、Workforce Identityは年払いでStarter 1ユーザー月6ドル、Core Essentials 14ドル、Essentials 17ドル。年間1,500ドルの最低契約額があるため、数十人規模だと単価より最低額が効きます。
• セキュリティ：2022年のLapsus$、2023年10月のサポートシステム侵害（最終的にサポート利用者18,400人が対象）という実績があります。裏返せば、その後に整備された管理者権限のゼロ・スタンディング・プリビレッジやIPバインディングを顧客側が設定しなければ、Oktaを入れてもリスクは減りません。
• 2026年の焦点：AIエージェントが人間の代わりにSaaSを叩き始めたため、Oktaの主戦場はCross App Access（XAA）とOkta for AI Agents（2026年4月30日GA）へ移っています。

OktaがIDaaSとして担う範囲と、2026年時点の製品構成

Oktaは2009年設立、本社はサンフランシスコ、Nasdaq上場（ティッカー：OKTA）のID管理専業ベンダーです。2026年1月31日時点で顧客は20,000社超、年間契約額10万ドル超の顧客が5,100社、Okta Integration Network（あらかじめ用意された連携先）は7,000超と、Form 10-Kに記載されています。2021年5月にはCIAM（顧客向けID管理）のAuth0を約65億ドルで買収し、従業員向けと顧客向けの両方を持つ体制になりました。日本法人はOkta Japan株式会社（2020年9月設立、渋谷ヒカリエ）で、国内パートナーは130社を超えます。

IDaaSの役割は、各SaaSがバラバラに持っていた「誰がログインできるか」の判断をクラウド側の1か所へ引き上げることです。人事システムで入社処理をすればアカウントが自動で作られ、退職すれば全SaaSから同時に消える。この一元化がOktaの本体で、SSOはその副産物にすぎません。

製品名で注意が必要なのは、日本語の解説記事に今も残る「Workforce Identity Cloud」「Customer Identity Cloud」という呼び方です。2026年1月期のForm 10-Kにこの2語は一度も出てきません。現在の主表記はOkta Platform（従業員・パートナー向け）とAuth0 Platform（自社製品のエンドユーザー向け）で、価格ページもこの2本立てです。Universal DirectoryやLifecycle Managementは前者に属する機能として並べられています（一部の製品ページには旧称のWorkforce Identity Cloudが残っているため、資料を読むときは発行時期を確認してください）。

Okta認証の仕組み：パスワードを渡さずにログインが成立する流れ

「okta 認証 とは」で調べる読者が知りたいのは、ログインボタンを押してからSaaSの画面が開くまでに何が起きているかです。

SSO：SaaSにパスワードを渡さず「認証済み」を証明する

利用者がSalesforceやSlackを開くと、アプリはログイン処理をOktaへ委任します。Oktaが本人確認を終えると、SAMLアサーションまたはOIDCのIDトークンという署名付きの証明書を発行し、アプリはその署名を検証してセッションを張ります。アプリ側にパスワードは一切渡りません。つまりSaaSが1社漏えいしても、そこから社内の認証情報が抜けることはないのがSSOの本質的な効果で、「ログインが1回で済んで楽」は副次的な話です。裏を返せば、Oktaのアカウント1つが乗っ取られれば連携する全アプリに届くため、次のMFAが必須になります。

適応型MFA：条件によって追加認証の有無を変える

Adaptive MFAは、同じユーザーでも状況に応じて要求を変えます。社内ネットワークの管理済みPCからならパスワードのみ、海外IPや未登録端末からならOkta Verifyのプッシュ承認や生体認証を追加、といった具合です。判定に使うのはIPアドレス、デバイスの管理状態、位置の変化、直近の振る舞いなどのシグナルで、上位プランのIdentity Threat Protectionを併用するとログイン後にリスクが上がった時点でセッションを打ち切る継続評価もできます。ログイン時に1度だけチェックする従来型MFAとの違いはここです。

Okta FastPass：デバイス内の秘密鍵で署名するパスワードレス認証

FastPassはOkta Verifyアプリを認証器として使うパスワードレス方式で、公式ドキュメントに書かれている流れは次のとおりです。

• 1. 鍵ペアの生成：Okta Verify登録時に、デバイス上で公開鍵と秘密鍵のペアを作る。秘密鍵はデバイスから出ず、Oktaのクラウドへ送られるのは公開鍵だけ。
• 2. チャレンジ発行：ログイン時、Oktaサーバがそのリクエスト固有のチャレンジ（乱数）を発行する。
• 3. 署名：Okta Verifyがデバイスのシグナルを集め、秘密鍵でチャレンジに署名して返す。
• 4. 検証：Oktaサーバが署名を検証し、正しければ認証成立。

やり取りされるのが「その場限りのチャレンジへの署名」なので、偽サイトが横取りしても再利用できません。フィッシング耐性があるとされるのはこの構造によるものです。ただしFastPassは秘密鍵がデバイスに紐づく認証器なので、端末を紛失・故障・機種変更すると、その端末で作った鍵は使えなくなります。バックアップ認証器（別端末のOkta VerifyやFIDO2セキュリティキー）を登録していない利用者は、管理者によるリセットを待つしかありません。設計時に代替手段を決めておく必要があります。

Okta Verify（オクタ アプリ）の対応OSと32bit版のサポート終了

「オクタ アプリ」で検索して辿り着く先は、ほぼOkta Verifyです。プッシュ通知の承認、TOTPコードの表示、生体認証、そして上記のFastPassを担う公式認証アプリで、公式のサポート対象OS（2026年7月時点）は次のとおりです。

見落としやすいのが、Windows版Okta Verifyの32bit版が2026年3月31日でサポート終了している点です。工場や店舗に古い32bit Windows端末が残っている環境では、MFAの展開計画より先に端末の棚卸しが要ります。ベータ版OSも公式には非サポートなので、検証端末を最新ベータへ上げたまま運用に載せないでください。

運用で問い合わせが集中するのは機種変更時です。Okta Verifyの登録情報とFastPassの秘密鍵は端末ごとに作られるため、新しい端末へアプリを入れ直しただけでは認証器は引き継がれません。旧端末が手元にあるうちに新端末でセルフサービス登録を済ませるか、旧端末を失ったあとは管理者にリセットしてもらう流れになります。端末更改が集中する時期は、この手順を事前に社内周知しておくとヘルプデスクの負荷を抑えられます。

Okta Platformの主要機能と、どの課題に効くか

機能名は多いものの、担当する課題で並べ替えると4系統に収まります。

Universal Directoryは、Active Directoryや人事システム、SaaS側のユーザー情報を1つのプロファイルに束ねる統合ディレクトリです。ここに集まった属性（部署・役職・雇用形態）がそのままアクセス判断の材料になるため、属性が汚れているとIDaaSを入れても権限設計が破綻します。導入前に人事マスタを正とするデータの流れを決めるのが、実務上いちばん時間のかかる工程です。

Lifecycle Managementは人事システムの入社・退職イベントを引き金に、SCIM連携でSaaS側のアカウントを自動作成・自動停止します。退職者アカウントの消し忘れという、監査で最も指摘されやすい穴を構造的に塞ぐのがこの機能です。より複雑な条件分岐（長期未ログインのアカウントを自動停止する、承認を挟んでから権限を付与する等）はノーコードのOkta Workflowsで組みます。

「誰がいつ、どのアプリに、どのデバイスからアクセスしたか」を追う監査ログはシステムログとして標準で保持され、Identity Threat Protectionを併用すると、そのログを異常検知とセッション失効に直結させられます。ログを取るだけで終わるか、検知して止めるところまで行くかがプランの分かれ目です。

Oktaの料金：スイート制の実額と年間1,500ドルの最低契約額

日本語の解説記事の多くは「従量課金制」とだけ書いて実額を出しません。2026年7月時点の公式価格ページは機能単品の積み上げではなくスイート（バンドル）制で、Workforce Identityは年間前払いで次のとおりです。

公式ページ上、Core Essentials（14ドル）とEssentials（17ドル）は掲載されている機能列挙が同一です。両者の差は価格ページからは読み取れないため、この2プランで迷ったら差分を営業・代理店に確認してください。見積もりでさらに効いてくるのは単価より「Workforce Identityには年間1,500ドルの最低契約額がある」という条件です。Starterを20人で契約すると年1,440ドルなので最低額に届かず、実質1,500ドルの支払いになります。ユーザー数が100人を切る規模では、単価表よりこの下限で総額が決まると考えたほうが現実に近い数字が出ます。

なお、かつて広く引用された「SSOが1ユーザー月2ドル、MFAが3ドル」といった単品価格は、現在の公式価格ページには掲載されていません。この単品表を載せている解説記事は情報が古いので、見積もりの根拠に使わないでください。日本国内では代理店経由の販売が中心で、国内SIerの導入支援パックと組み合わせる形も一般的です（IDaaS「Okta」導入支援｜ラックのスターターパック3プラン比較と従業員ID管理の課題解決で国内パックの構成を整理しています）。

Oktaのセキュリティ評価：過去インシデントと、顧客側が設定すべき対策

「オクタ セキュリティ」で調べる人が本当に気にしているのは機能一覧ではなく、ID基盤そのものが破られた過去をどう評価するかです。公表済みの3件を、影響範囲と原因の所在で整理します。

公表されている3件のインシデント

• 2022年1月・Lapsus$（サプライヤ経由）：委託先Sitelの端末が侵害されました。当初「最大366社に影響の可能性」と発表されましたが、公式の最終調査では、攻撃者が実際に端末を制御したのは1月21日の25分間のみ、社内管理アプリ内で実際にアクセスされたのは2テナントだけと結論づけられています。
• 2023年10月・サポートシステム侵害：不正アクセス期間は2023年9月28日〜10月17日。当初発表は「顧客の1%未満（134社）」でしたが、同年11月29日の更新で範囲が拡大し、攻撃者がサポート利用者全員の氏名とメールアドレスを含むレポートを取得していたこと（対象18,400ユーザー）が公表されました。最終報告は2024年2月8日、独立フォレンジックにより既知の範囲を超える活動は確認されず、本番サービスへの影響は無しとされています。
• 2024年10月・AD/LDAP委任認証のバイパス脆弱性：キャッシュキーの生成方式に起因し、パスワード無しに認証が通り得た不具合。成立条件はAD/LDAP委任認証を使い、MFAを有効化しておらず、ユーザー名が52文字以上で、過去のログインがキャッシュ済み、という組み合わせに限られます（MFAを有効にしていれば影響しません）。影響期間は2024年7月23日〜10月30日で、10月30日に社内で発見・同日修正、11月1日にアドバイザリが公開されました。侵害ではありませんが、条件に当てはまる環境ではこの期間のログ監査が推奨されています。

3件の履歴の評価：ベンダー起因か、顧客側の設定起因か

結論を言えば、この3件を理由にOktaを避けるのは合理的ではない一方、「Oktaを入れたから安全」も同じくらい誤りです。3件のうち2件はOkta本体ではなく委託先端末とサポート系システムが起点で、本番の認証基盤そのものが破られたわけではありません。しかし2023年の事案では、盗まれたHARファイル（サポート用の通信ログ）に含まれるセッショントークンから顧客側で被害が出ました。ここで被害を免れた顧客と受けた顧客を分けたのは、管理者アカウントのMFA有無とネットワークゾーン制限の設定です。つまり差がついたのはベンダーの側ではなく、顧客側の設定でした。

Oktaは2024年2月にSecure Identity Commitmentを公表し、事案後の是正として管理者ロールのゼロ・スタンディング・プリビレッジ（常時付与された特権を無くす）、機微な管理操作へのMFA必須化、セッション乗っ取りを防ぐIPバインディング、API利用のネットワークゾーン制限を実装しています。これらは既定で有効になるものばかりではなく、テナント側で有効化して初めて効きます。導入時に最低限確認すべきは次の4点です。

• Super Admin権限を常設せず、必要な時だけ昇格させる運用にしているか
• 管理コンソールへのアクセスをネットワークゾーンで絞り、管理者にフィッシング耐性のある認証器（FastPassやFIDO2）を必須化しているか
• サポートへ調査用ファイル（HAR）を送る際に、セッショントークンをサニタイズしているか
• システムログをSIEMへ流し、管理者操作の異常を検知できるか

認証・準拠状況（日本企業が確認すべき範囲）

Okta公式のトラストサイトには、ISO 27001／27017／27018、SOC 1・2・3、FedRAMP High（Okta for Government Highが2023年3月28日に取得）、DoD IL4、IRAP、C5、TISAX、PCI DSS v4.0.0などが列挙されています。一方でISMAP（政府情報システムのクラウドサービス登録制度）については、Okta公式の準拠一覧に記載が見当たらず、本稿執筆時点で登録の有無を一次情報で確認できていません。官公庁・自治体案件で必須要件となる場合は、必ずISMAPポータルのクラウドサービスリストと販売代理店に直接確認してください。「グローバル認証を多数持っている＝ISMAP登録済み」ではありません。

AIエージェント時代のID管理：Cross App AccessとOkta for AI Agents

2025年以降、Oktaの製品開発はAIエージェントへ大きく寄っています。背景は単純で、人間ではなくAIエージェントがSaaSのAPIを叩くようになると、従来のOAuth同意画面（人間がクリックする前提の仕組み）が破綻するためです。

Cross App Access（XAA）は、Identity Assertion Authorization Grant（ID-JAG）というJWTを使い、IdPであるOktaがアプリ間・エージェント間の認可を仲介する拡張仕様です。2026年6月23日には25以上の新規統合が発表され、リクエスト側にClaude・Cursor・VS Code・Zoom、リソース側にSlack・Atlassian・Figma・Datadogなどが並び、公式MCP SDKがXAAをEnterprise-Managed Authorization拡張として採用しています。ただしこの統合群をOkta Integration Network経由で利用できるのは2026年8月からと発表されており、発表時点＝即利用可ではない点に注意してください。エージェント自体のID管理を担うOkta for AI Agentsは2026年4月30日にGAとなり、エージェントの検出・登録、Agent Gateway、ユニバーサルログアウト（暴走時のキルスイッチ）を提供します。

ここで留保が必要なのがIPSIEです。Oktaが2024年10月にOpenID Foundationで立ち上げたエンタープライズID相互運用の仕様策定活動で、2026年7月時点でもFinal SpecificationもImplementer’s Draftも0件、ワーキンググループのドラフト段階にとどまります。「IPSIEという標準に準拠しているから安心」という書き方をしている記事がありますが、まだ標準として確定していません。技術詳細はOkta Cross App Access（XAA）とは？AIエージェントの認可を統制する新標準を2026年動向で解説で扱っています。

導入判断：Oktaが向く企業と、選ぶべきでない企業

向いているのは、SaaSを数十本使っていて、しかもMicrosoft以外の比率が高い企業です。Universal DirectoryとOkta Integration Networkの7,000超の連携先が効くのはこの条件のときで、AD／人事システム／SaaSがベンダー横断で散らばっているほど費用対効果が出ます。国内では日立ソリューションズ・伊藤忠テクノソリューションズ・丸紅情報システムズなどがOktaの取扱パートナーとして製品ページと導入メニューを公開しており、Okta Japanのパートナーは130社を超えます（2025年9月時点）。日本語での導入支援を代理店から受けられることは、エンタープライズでは実務上の判断材料になります。

逆に、選ぶべきでない場面もはっきりしています。

• Microsoft 365中心で他SaaSがほとんど無い企業：Microsoft Entra IDがM365ライセンスに含まれるため、Oktaを別途契約すると同じ機能に二重で払うことになります。
• 従業員数十人規模でコストを最小化したい企業：年間1,500ドルの最低契約額があるため、1人あたり単価の安さが効きません。
• ID基盤を自社データセンター内に置く必要がある企業：SaaS前提のOktaでは要件を満たせません。この場合はOSSのIDaaSを自社で運用する選択肢になります（比較の観点はKeycloakとは？メリット・デメリットとAuth0・Okta・Cognito比較で導入を判断【2026年版】にまとめています）。

もう1点、日本企業でよく問題になるのがデータの保管場所です。Okta公式ドキュメントにはインフラリージョンとしてAWS Japanの記載がありますが、「日本国内にデータが留まることの保証範囲」までは公式一次情報で明示されていません。個人情報保護法の越境移転や社内規程で国内保管が必須なら、契約前に自社テナントがどのセル（Oktaがテナントを収容するインフラ単位。リージョンごとに用意され、テナント作成時に割り当てられる）に載るのかと、保管されるデータの範囲を書面で確認するのが安全です。

よくある質問

Oktaの読み方は？社名の由来は何ですか？

日本語では「オクタ」です。日本法人も「Okta Japan株式会社」として登記されています。一般名詞のoktaは雲量を8分割で表す気象単位（0〜8オクタ）で、クラウド企業の名としてこれに由来すると語られますが、Okta社が公式に由来を説明した一次情報は確認できていません。

無料で試せますか？小規模でも契約できますか？

Okta Platformには30日間の無料トライアルが用意されており、事前に管理コンソールとSSO・MFAの挙動を確認できます。ただし本契約には年間1,500ドルの最低契約額があるため、ユーザー数が20〜30人規模だと1人あたり単価では計算どおりになりません。国内では代理店経由の購入・請求が一般的なので、日本円建ての条件は取扱パートナーに確認してください。

Microsoft Entra ID（旧Azure AD）ではなくOktaを選ぶ理由は？

ベンダー中立性です。Entra IDはMicrosoft製品との統合が最も深い一方、Oktaは特定のクラウドベンダーに寄らず7,000超の連携先を持ちます。Google Workspace・AWS・Salesforce・国内SaaSが混在する環境ほどOktaが有利で、M365にほぼ閉じている環境ではEntra IDのほうが合理的です。

複数のADドメインやフォレストを1つのOktaテナントに統合できますか？

できます。Universal Directoryは複数のADドメイン／フォレストからの同期を前提に設計されており、各ADにAD Agentを配置して1テナントへ集約します。ただし同一ユーザーが複数ドメインに存在する場合、どの属性を正とするかのマッチング規則（メールアドレス基準など）を先に決めないと重複プロファイルが生まれます。

Auth0とOktaは別の製品ですか？使い分けは？

2021年にOktaがAuth0を買収し、現在は同社の2プラットフォームとして併存しています。従業員・パートナーのID管理はOkta Platform、自社サービスのエンドユーザー向けID管理（会員登録・ソーシャルログイン等）はAuth0 Platformという住み分けです。開発者が自社アプリに認証を組み込む用途ならAuth0側を検討します。

関連記事

• Okta Cross App Access（XAA）とは？AIエージェントの認可を統制する新標準を2026年動向で解説
• IDaaS「Okta」導入支援｜ラックのスターターパック3プラン比較と従業員ID管理の課題解決
• Keycloakとは？メリット・デメリットとAuth0・Okta・Cognito比較で導入を判断【2026年版】
• Keycloakとは？IDおよびアクセス管理の包括的なソリューション