NextcloudでONLYOFFICEの「トークンが無効です」エラーを解決する

NextcloudがONLYOFFICE Docsに接続した際に「トークンが無効です」というエラーが表示される場合は、コネクタのJWTシークレットをDocument Serverが実際に使用しているシークレットと一致させてください。ONLYOFFICE Docs 7.2以降では、JWT検証はデフォルトで有効になっており、シークレットは自動的に生成されます。Nextcloudの設定のみを変更したり、Dockerコンテナで生成された構成ファイルを編集したりすると、両者の同期が取れなくなる可能性があります。

JWTを有効にしたままにしてください。まず、有効なシークレットとデプロイメントタイプを特定し、適切な設定を更新してから、コネクタの接続チェックを実行します。チェックでは接続が成功したと報告されるはずです。ブラウザエディタが開いただけでは、ドキュメントのダウンロードやコールバックが正常に機能しているとは言えません。

そのエラーは何を意味していますか?

JWT(JSON Web Token)は、NextcloudとONLYOFFICE Docs間のリクエストが信頼できることを検証するために使用される署名付きトークンです。コネクタは設定済みのシークレットを使用してリクエストに署名し、ドキュメントサーバーは設定済みのシークレットを使用してリクエストを検証します。署名シークレットが異なる場合、トークンの署名を検証できず、リクエストは拒否されます。

最も一般的な原因としては、古いインストール環境からコピーされたシークレット、Nextcloudに入力されていない自動生成されたシークレット、コンテナの再作成によって適用されなかった変更されたDocker環境変数、またはドキュメントサーバー構成におけるシークレット値の不一致などが挙げられます。コネクタとドキュメントサーバーで同じヘッダー名が使用されていない場合、カスタムJWTヘッダーも不一致の原因となる可能性があります。

この記事では、JWTの不一致について説明します。エラーメッセージに「サーバーに接続できません」「証明書が無効です」「ドキュメントをダウンロードできません」と表示される場合は、サーバーアドレス、TLS証明書、およびNextcloudからドキュメントサーバーへのネットワークパスを個別に調査してください。JWTの修正では、これらの問題は解決しません。

1. アクティブなドキュメントサーバーのシークレットを見つける

実行中のドキュメントサーバーの構成を使用してください。以前のコンテナまたはサーバーから記憶されたシークレットがまだ有効であると想定しないでください。

  • Linux: inspect /etc/onlyoffice/documentserver/local.json。
  • Windows:検査%ProgramFiles%\ONLYOFFICE\DocumentServer\config\local.json。
  • Docker:実行中のコンテナからシークレットを読み取ります。公式イメージでは、このコマンドを使用してセッションシークレットを読み取ることもできます。
sudo docker exec <containerID> /var/www/onlyoffice/documentserver/npm/json -f /etc/onlyoffice/documentserver/local.json 'services.CoAuthoring.secret.session.string'

実際のコンテナ名またはIDに置き換えてください<containerID>。返された値は認証情報として扱ってください。サポートフォーラム、スクリーンショット、公開ログなどに貼り付けないでください。

では、、、およびのlocal.json値を比較してください。この標準設定では、これらはすべて同じ値になるはずです。また、ブラウザ、リクエスト受信ボックス、リクエスト送信ボックスでトークン検証が有効になっていることを確認してください。ドキュメントのバージョン7.2より前では、トークン検証を明示的に有効にする必要がありますが、それ以降のバージョンではデフォルトで有効になっています。services.CoAuthoring.secret.inbox.stringservices.CoAuthoring.secret.outbox.stringservices.CoAuthoring.secret.session.string

2. NextcloudのONLYOFFICEコネクタを更新する

  1. Nextcloud 管理者としてサインインし、[設定] > [管理] > [ONLYOFFICE]を開きます。
  2. サーバー設定で、実行中のドキュメントサーバー上で見つかった正確なシークレットを「シークレットキー」フィールドに入力してください。先頭または末尾にスペースを入れないでください。また、シークレット自体の一部である場合を除き、引用符を追加しないでください。
  3. デプロイメントでカスタムヘッダーを使用している場合は、JWTヘッダーの設定を確認してください。コネクタのjwt_header設定とドキュメントサーバーで設定されているトークンヘッダーは一致している必要があります。意図的にヘッダーをカスタマイズしていない場合は、この修復作業の一環としてヘッダーを変更しないでください。
  4. 設定を保存してください。両側でJWTを有効にしたままにしてください。

ドキュメントに記載されているコネクタ設定は、occNextcloudのインストールディレクトリからNextcloudのコマンドを使用して変更することもできます。

sudo -u www-data php occ config:app:set onlyoffice jwt_secret --value='YOUR_SECRET'

実際の値に置き換えてくださいYOUR_SECRET。シェルの引用符は句読点を保持するのに役立ちますが、シングルクォートを含む秘密情報は、コマンドラインに直接挿入するよりも安全な方法が必要です。コマンドライン引数は、特権プロセス検査やシェル履歴にも表示される可能性があります。可能な限り管理者インターフェースを使用し、保存された値を公開せずに検証してください。

3. インストール環境に合わせて適切な方法で変更を適用してください。

DockerまたはDocker Compose

Dockerデプロイメントの場合、自動生成されたファイルを手動で編集するのではなく、コンテナ環境を通してJWTを設定してくださいlocal.json。ドキュメントサーバーサービス定義にも同じシークレットを設定してください。

environment:
  - JWT_ENABLED=true
  - JWT_SECRET=YOUR_SECRET

Compose ファイルを変更した後、環境を反映させるためにドキュメント サーバー コンテナを再作成します。たとえば、Compose ファイルを含むディレクトリから次のようにします。

docker compose up -d --force-recreate <documentserver-service>

独自の Compose ファイルからサービス名を置き換えてください。単純な再起動では、変更された環境値は既存のコンテナに適用されません。 を使用する場合は、更新されたと の値docker runを使用してコンテナを再作成し、既存のポート、ボリューム、およびその他の必要なオプションを保持してください。これらの設定と永続的なデータマウントを確認するまでは、本番環境のコンテナを削除しないでください。JWT_ENABLEDJWT_SECRET

コンテナが起動したら、上記のコマンドを使用してアクティブなシークレットを再読み込みし、値がNextcloudと一致していることを確認してください。本番環境用のシークレットを公開されているComposeファイルやソースリポジトリに配置しないでください。

LinuxパッケージまたはWindowsのインストール

にカスタムシークレットを意図的に設定する場合はlocal.json、3 つのシークレット フィールドが一致し、必要なトークン検証値が有効になっていることを確認してください。変更を適用するには、関連するドキュメント サーバー サービスを再起動します。現在の ONLYOFFICE の手順ではds-converter、 Linux では、、、、ds-docserviceがds-metricsリストされています。別のサービス スーパーバイザーによって管理されているインストールでは、その設定に適した再起動方法が必要になる場合があります。Windows では、構成を保存した後、ONLYOFFICE サービスを再起動してください。

再起動後も不一致が解消されない場合は、通常、生成された構成ファイルまたはデプロイメント環境が編集したファイルを上書きしていることを意味します。Docker の場合は、修正内容を環境変数に移動してコンテナを再作成してください。パッケージ化されたデプロイメントの場合は、設定を変更する前に、アクティブな構成とサービスの起動構成を確認してください。

修理を確認する

  1. Nextcloudのインストールディレクトリで、公式コネクタチェックを実行します。
sudo -u www-data php occ onlyoffice:documentserver --check

インストール環境に適したウェブサーバーアカウントを使用してくださいwww-data。コマンドは接続成功を報告するはずです。それでも無効なトークンが報告される場合は、実行中のドキュメントサーバーのアクティブなシークレットが Nextcloud と完全に一致していること、およびカスタム JWT ヘッダーが一致していることを再度確認してください。

  1. ONLYOFFICEを使ってNextcloudから小さなテスト文書を開きます。エディタが読み込まれることを確認し、簡単な変更を加えて保存し、エディタを閉じてから、再度ファイルを開いて変更が反映されていることを確認します。
  2. チェックの結果、ネットワークエラーまたは証明書エラーが報告された場合は、JWT 値の変更を中止してください。Nextcloud がドキュメントサーバーのアドレスにアクセスできること、およびドキュメントサーバーが Nextcloud のコールバックアドレスにアクセスできることを確認してください。可能な限り信頼できる TLS 証明書を使用してください。証明書の検証を無効にするのは安全でない回避策であり、トークン検証の問題を解決しません。

これらのチェックは、構成された接続と基本的な保存パスが正しく機能することを確認するものです。ただし、すべてのリバースプロキシ経路、外部ストレージ構成、またはマルチサーバー構成が正しいことを証明するものではありません。これらのパスを使用する場合は、別途テストしてください。

公式資料

構成の詳細は、2026年10月9日に公式のONLYOFFICEドキュメントおよびコネクタリポジトリと照合されました。UIラベルとサービス管理は、コネクタ、オペレーティングシステム、および展開方法によって異なる場合があります。

コメントを残す

ONLYOFFICE PDFエクスポートの失敗の原因を特定する

ONLYOFFICE PDFエクスポートの失敗の原因を特定する

ブラウザのダウンロードに関する問題とサーバー側の変換エラーを区別し、適切なログまたはアクセスチェックを使用して、PDFエクスポートが正常に機能するようにしてください。

NextcloudでONLYOFFICEの「トークンが無効です」エラーを解決する

NextcloudでONLYOFFICEの「トークンが無効です」エラーを解決する

ONLYOFFICE DocsとNextcloudで使用されているJWTシークレットを照合し、DockerまたはLinuxインストールに安全に適用し、認証を弱めることなく接続を検証します。

Ubuntu 24.04にONLYOFFICE Workspace Communityをデプロイする

Ubuntu 24.04にONLYOFFICE Workspace Communityをデプロイする

公式のDockerスクリプトを使用して、Ubuntu 24.04にONLYOFFICE Workspace Communityをインストールし、サーバー要件を確認し、必要に応じてメールをスキップし、ポータルが安全に動作することを確認します。

ONLYOFFICE JWTシークレットをサーバーとコネクタ間で設定する

ONLYOFFICE JWTシークレットをサーバーとコネクタ間で設定する

ONLYOFFICE Docsとそのコネクタに対応するJWTシークレットを設定します。Linuxパッケージ、Dockerデプロイメント、および検証のための安全な手順も含まれています。

ONLYOFFICE Docsを、あなたのロゴとテーマカラーでブランド化しましょう。

ONLYOFFICE Docsを、あなたのロゴとテーマカラーでブランド化しましょう。

組み込み型のONLYOFFICE Docsエディタに、カスタムテーマファイルとエディタ設定を使用して、会社のロゴとインターフェースカラーを設定できます。エディション制限と展開チェックについては、こちらをご覧ください。

DOCX形式でエクスポートする際に、ライターの修正履歴を表示する

DOCX形式でエクスポートする際に、ライターの修正履歴を表示する

Writerで編集履歴を追跡し、編集可能なODTソースを保持し、共有する前にエクスポートしたDOCXファイルをWordで確認します。

SLES 15でFIPSモードを有効にし、ブート状態を確認する

SLES 15でFIPSモードを有効にし、ブート状態を確認する

SUSEのSP7の手順に従ってFIPSモードを有効にし、安全に再起動し、アクティブなポリシーを確認し、コンプライアンス要件で検証済みモジュールが必要かどうかを確認してください。

SLES上にLUKS暗号化データボリュームを設定する

SLES上にLUKS暗号化データボリュームを設定する

新しい暗号化されたSLESデータボリュームに対してYaSTとcryptsetupを比較し、LUKS1またはLUKS2を選択して、ロック解除とマウントの動作が安全に行われることを確認します。

SLES 15 上で RMT を使用してローカル SUSE アップデート サーバーを構築する

SLES 15 上で RMT を使用してローカル SUSE アップデート サーバーを構築する

SLES 15 上に RMT をセットアップし、権限のあるリポジトリをミラーリングし、テストクライアントから HTTPS 登録とパッケージへのアクセスを確認します。

YaSTでSSSDを使用してSLES 15をActive Directoryに参加させる

YaSTでSSSDを使用してSLES 15をActive Directoryに参加させる

YaSTのSSSDベースのログオン管理を使用してSLES 15をADに接続し、ディレクトリ検索、ドメインログイン、およびKerberosチケットを確認します。