ごきげんよう、IDチームのわかなです！
今回は、プロキシやSWG（Secure Web Gateway）を導入している環境で、Oktaのログインや画面表示が突然おかしくなるというトラブルについて解説します。
お問い合わせ内容
設定は何も変えていないはずなのに、急にOktaが使えなくなった
一部のブラウザや端末だけエラーが出る
調査を進めると、共通する原因はOktaが利用する関連ドメインへの通信がプロキシでブロックされていました。Oktaを正常に動かすには *.okta.com だけでなく、CDNや証明書検証用など複数のドメインへの疎通を許可する必要があります（公式ドキュメント：Allow access to Okta IP addresses）。
もしこのような状況になってしまった方が、即解決に繋がりますように・・・！
プロキシは何の役割をしている？
企業がプロキシサーバーやSWGを導入する主な目的は以下のとおりです。
- 通信の可視化・ログ取得：誰がいつどのサイトにアクセスしたかを記録し、セキュリティ監査やインシデント対応に活用する
- Webフィルタリング：業務に不要なサイトやマルウェア配布サイトへのアクセスをブロックする
- SSL/TLSインスペクション：暗号化された通信の中身を検査し、マルウェアや情報漏洩を検知する
- アクセス制御：許可リスト/拒否リストにもとづいて、特定ドメインへの通信を制御する
セキュリティ要件が厳しい環境では、「許可されたドメイン以外への通信はすべてブロックする」 というホワイトリスト方式が採用されていることも珍しくありません。このような環境では、新しいSaaSを導入するたび、そのサービスが通信するドメインをすべて洗い出して許可リストに追加する作業が必要になります。
Oktaに必要な許可設定の全体像
Oktaを導入する際に *.okta.com を設定するだけでは足りません！！！Okta公式ドキュメント「Allow access to Okta IP addresses」には、許可が必要なドメインが明記されています。以下の表に整理しました。
許可すべきドメイン一覧
| 区分 | ドメイン | ポート | 用途 |
|---|---|---|---|
| 必須 | *.okta.com | 443 | テナント本体（ログイン、管理コンソール、API等） |
| 必須 | *.oktacdn.com | 443 | ログイン画面・ダッシュボードの静的リソース配信（CDN）。IPv6クライアントがある場合はIPv6も許可 |
| 必須 | *.awsglobalaccelerator.com | 443 | AWSグローバルアクセラレータ経由の接続ルーティング |
| CDN | okta-featureflag-edge.azureedge.net | 443 | フィーチャーフラグ（機能フラグ）の配信 |
| 証明書検証 | ocsp.digicert.com | 80 | OCSP（証明書の失効確認） |
| 証明書検証 | crl3.digicert.com / crl4.digicert.com | 80 | CRL（証明書失効リスト）のダウンロード |
| プレビュー環境 | *.oktapreview.com / *.mtls.oktapreview.com | 443 | サンドボックス環境を利用する場合 |
| EMEA環境 | *.okta-emea.com / *.mtls.okta-emea.com | 443 | EMEAリージョンのテナントを利用する場合 |
| mTLS | *.mtls.okta.com | 443 | 相互TLS認証を使用する場合 |
| Kerberos | *.kerberos.okta.com / *.kerberos.okta-emea.com / *.kerberos.oktapreview.com | 443 | デスクトップSSO等でKerberos認証を使用する場合 |
| 米国政府向け | *.okta-gov.com / *.mtls.okta-gov.com / *.okta.mil / *.mtls.okta.mil | 443 | GovCloud・軍事環境 |
*.okta.com、*.oktacdn.com、*.awsglobalaccelerator.com は必須です。プレビュー環境を利用している場合は *.oktapreview.com も追加してください。
IPアドレスの許可
ドメインの許可に加えて、Oktaエージェント（AD Agent、LDAP Agentなど）をオンプレミスで稼働させている場合は、OktaのIPアドレスレンジもインバウンドのファイアウォールルールに追加する必要があります。
IPアドレスの最新リストはOkta公式が公開しているJSONファイル「Okta IP range allowlist（JSON）」から取得できます。
なお、IPアドレスは変更される可能性があるため、ドメイン名のワイルドカード指定での許可を推奨します。
ドメインがブロックされると何が起きる？
許可が漏れているドメインによって、症状が異なります。
.oktacdn.com がブロックされている場合
- ログイン画面が真っ白になる、またはロード中のまま進まない
- ログインボタンが表示されない、押しても反応しない
- 特定のブラウザだけでエラーが出る（ブラウザごとのCSP処理の違いによる）
- Okta経由のSSO先（Microsoft 365、Salesforceなど）にアクセスできない
okta-featureflag-edge.azureedge.net がブロックされている場合
- Okta管理コンソールの一部の機能が正常に動作しない
- 新機能やUI変更が正しく反映されない
ocsp.digicert.com / crl*.digicert.com がブロックされている場合
- SSL/TLS接続自体がエラーになる
- 「この接続は安全ではありません」といったエラーが表示される
- ブラウザやOSによって挙動が異なる（証明書失効確認をスキップするブラウザもある）
.awsglobalaccelerator.com がブロックされている場合
- Oktaへの接続がタイムアウトする、または極端に遅い
- 特定のネットワーク経路でのみ問題が発生する
厄介なのは、「認証の仕組み自体は正常に動いているように見える」 ケースがあることです。例えば *.oktacdn.com がブロックされている場合、Oktaテナントへの認証リクエストは通っているため、管理者側のOktaログにはエラーが記録されないこともあり、原因特定が難しくなります。
なぜ「今まで大丈夫だった」のに急に使えなくなるの？
「ずっと使えていたのに急に動かなくなった」パターンは、社内で問題になりやすいケースです。主に2つの原因があります。
1. Okta側のCDNアドレス更新
Okta社は、CDNのIPアドレスやサブドメインの更新を定期的に実施しています。たとえば、2024年11月以降、CDNのIPv6対応に伴うアドレス更新が順次行われました（Okta Supportポータルにてアナウンス済み）。
プロキシ側でIPアドレスベースの許可設定をしていた場合、CDNのアドレスが変わったタイミングで通信が遮断されます。ドメイン名（*.oktacdn.com）でのワイルドカード許可が推奨されるのはこのためです。
2. プロキシ/SWG側のポリシー変更
セキュリティチームによるフィルタリングルールの更新や、SWG製品のアップデートによって、それまで暗黙的に許可されていた通信が急にブロックされるケースもあるのでご注意ください。
まとめ
プロキシやSWGを導入している環境では、Okta関連ドメインの許可漏れがさまざまなトラブルの原因になります。
押さえておくべきポイントは以下のとおりです。
.okta.comだけでなく.oktacdn.com、.awsglobalaccelerator.com、okta-featureflag-edge.azureedge.netも許可する- 証明書検証用の
ocsp.digicert.com等は ポート80 での許可が必要 - IPアドレスベースではなくドメイン名ベースのワイルドカード指定で許可する
- Okta側のCDNアドレス更新（IPv6対応等）にも継続的に注意を払う
「急に画面が崩れた」「一部の環境だけログインできない」といった事象に遭遇したら、まず公式ドキュメントの許可ドメインリストと自社のプロキシ設定を突き合わせることから始めてみてください。また、ブラウザの開発者ツールやプロキシのログで、上記ドメインへの通信がブロックされていないか確認してみてください。
この記事が、皆様の導入設計やトラブルシューティングの一助になれば幸いです！
