発表日 フェーズ1のロールアウト フェーズ2のロールアウト
2025年4月30日 2025年4月30日~5月30日 2026年6月30日~2027年4月1日

本日より、お客様はアクセストークンとリフレッシュトークンの有効期限のサポートとともに、OAuth 2.0標準に準拠したOAuthリフレッシュトークングラントタイプを採用できます。マーケットプレイスでインテグレーションやアプリを公開するサードパーティのアプリ開発者は、 refresh_token フローを2026年1月31日までに採用する必要があります。お客様は、2027年4月1日までにこれを行う必要があります。

このお知らせの内容は以下のとおりです。

  • 変更内容
  • Zendeskがこれらの変更を行う理由
  • 必要となる作業

変更内容

Zendeskでは、必須トークンの有効期限に移行するために、OAuth更新トークングラントタイプを2つのフェーズに分けて導入しています。このグラントタイプは、すでに期限切れになっているか、まもなく期限切れになるアクセストークンを更新するために使用されます。本日よりご利用いただけます。サードパーティのアプリ開発者は、2026年1月31日までにOAuth更新フローを採用する必要があり、2027年4月1日までにすべてのお客様に使用が求められます。

このフローは、grant_type: refresh_tokenを使用して、有効なrefresh_tokenパラメータを/oauth/tokensエンドポイントに対して渡すことで、新しいOAuthアクセストークンを生成します。リクエストが成功すると、リフレッシュトークンが返され、以前のアクセストークンとリフレッシュトークンが削除されます。フローとトークンの有効期限の徹底的なテストを refresh_token可能にするため、および authorization_code両グラントタイプを利用して refresh_tokenアクセストークンの有効期限を設定する際に、expires_inおよびrefresh_token_expires_inパラメータを/oauth/tokensエンドポイントに渡して、アクセストークンの有効期限を設定することも可能です。有効期限を設定した場合、それは適用され強制されます。

重要:更新トークンの有効期限にはアクセストークンが必要です。ZendeskがリフレッシュトークンSupportを追加する前に作成されたOAuthクライアントについては、認証リクエスト中に明示的にexpires_inを渡す必要があります。そうしないと、アクセストークンは期限切れにならず、リフレッシュトークンも発行されません。2026年4月30日以降に作成されたOAuthクライアントの場合、トークンの有効期限は自動的に設定されます。旧バージョンのクライアントの場合、リフレッシュトークンフローを採用するには、明示的にexpires_inを設定する必要があります。

更新トークンは、すべての新しいOAuthトークン要求に対して付与されます。既存のOAuthトークンはリフレッシュできません。既存のアプリケーションや統合はこれまで通り正常に動作し続けます。2026年4月30日以降に作成されたOAuthクライアントには、自動的にデフォルトのTTLが適用されます。

トークンタイプ デフォルトのTTL(有効期限) 最小TTL(有効期限) 最大TTL(有効期限)
アクセストークン 30分 5分 48時間
更新トークン 30日 7日 90日

フェーズ1:導入(現在利用可能)

カスタマーとサードパーティのアプリ開発者がrefresh_tokenフローを採用できるようになりました。このグラントタイプは、すでに期限切れになっているか、まもなく期限切れになるアクセストークンを更新するために使用されます。

フェーズ2:施行(2026年6月以降)

Zendeskは、既存のローカルOAuthクライアントにトークンの有効期限の適用を開始します。フェーズ2の適用は、2026年6月30日から2027年4月1日までの月次波で行われます。実施予定日に、アカウント内のすべてのローカルOAuthクライアントにトークンの有効期限が適用されます。施行予定日より前にお知らせいたします。

Zendeskがこの変更を行う理由

このアップデートにより、さらにOAuth 2.0標準に準拠することで、お客様と開発者により堅牢で柔軟なAPI認証が提供されます。 

必要となる作業

APIリクエストの認証にOAuthを使用している場合、アプリケーションまたはインテグレーションはrefresh_tokenグラントタイプを採用する必要があります。詳細については、「OAuth認証をアプリケーションで使用する」を参照してください。

OAuth クライアントがリフレッシュ トークン Support の導入前に作成されている場合は、認可時に明示的にexpires_inを渡す必要があります。リフレッシュトークンは、アクセストークンの有効期限が切れるように構成されていない限り発行できません。古いクライアントでは、これは自動的に設定されません。認可リクエストをチェックして、施行日より前にexpires_inが通過していることを確認してください。

この発表に関連するフィードバックや質問がある場合は、コミュニティフォーラムにアクセスしてください。このフォーラムでは、お客様から寄せられた製品フィードバックを収集し管理しています。Zendesk製品に関する一般的なサポートについては、Zendeskお客様サポートにお問い合わせください。

翻訳に関する免責事項:この記事は、お客様の利便性のために自動翻訳ソフ トウェアによって翻訳されたものです。Zendeskでは、翻訳の正確さを期すために相応の努力を払っておりますが、翻訳の正確性につ いては保証いたしません。

翻訳された記事の内容の正確性に関して疑問が生じた場合は、正式版である英語の記事 を参照してください。

Powered by Zendesk