製品ライフサイクル

製品のリリース段階、非推奨化、サポート終了、移行プロセス、進行中の移行など、Auth0 の製品ライフサイクルについて説明します。

Auth0 では、製品開発において次の方針を掲げています。

• お客様に価値を早期から継続的に提供し、そのフィードバックに基づいて改善を重ねる
• お客様を深く理解し、あらゆる意思決定においてその視点を考慮する
• より適切な判断を行えるよう、データを継続的に収集・分析する
• 機能追加の際には、製品全体の現在の姿、理想的な姿、将来の姿を見据えて設計する

このドキュメントでは、Auth0 プラットフォームにおける後方互換性のある変更 (非破壊的変更) と、後方互換性のない変更 (破壊的変更) について説明します。これらの違いを理解することで、開発者は Auth0 サービスの利用時にアプリケーションへ生じる可能性のある影響を事前に把握できます。

このドキュメントでは、統合に関する想定を明確にするため、一般的な変更とその互換性をまとめています。ここで説明する変更は、網羅的なものではありません。破壊的変更の詳細については、以下のトピックを参照してください。

お読みください	確認できる内容
製品リリース段階	Auth0 が製品機能をどのように段階的に提供し、リリースし、終了するか。
移行プロセス	Auth0 の非推奨化と移行のプロセスの仕組み。
非推奨化と移行	現在の非推奨化の内容と、新しい動作や機能へ移行する方法。
過去の移行	これまでにお客様向けに有効化された移行。

​

Auth0 APIs

Auth0 は、Authentication API や Management API などの API を提供・維持しています。これらの API はそれぞれ、文書化された API 仕様と関連成果物に基づき、Auth0 と顧客の間の契約を定義しています。Auth0 は、IETF や OIDC などの標準化団体が策定した広く認められた標準に従っています。標準が存在しない場合は、ベストプラクティスに沿って独自の API を開発します。

これらの API への変更は、後方互換性の有無にかかわらず、機能、セキュリティ、またはパフォーマンスを向上させるために、必要に応じて行われます。

​

後方互換性のある非破壊的変更

後方互換性のある変更は、Auth0 プラットフォームと顧客アプリケーション間の相互運用性を損なわず、顧客が直ちに対応したり、移行プロセスに参加したりする必要もありません。

非破壊的変更の例は次のとおりです。

• 不透明文字列: 不透明文字列 (例: トークン、ID) の形式やサイズは変更される場合があります。クライアントは、サイズや形式が固定であることを前提にしないでください。不透明文字列の最大サイズは 4096 文字を超えません。
• JWT のサイズ: OAuth 仕様 (RFC6749) では、JWT 認証情報のサイズは定義されていません。Auth0 が発行する JWT のサイズは変動する場合があるため、クライアントは特定のサイズを前提にしないでください。
• 認可コードのサイズ: OAuth 仕様に従い、認可コードのサイズは変動する可能性があることをクライアントは想定しておく必要があります。
• 認識されないレスポンスパラメーター: クライアントは、認識されないレスポンスパラメーターを無視する必要があります。これにより、Auth0 は現在の機能に影響を与えることなく新機能を追加できます。
• 新しいリソース、フィールド、ヘッダー、またはスコープ: 新しい API リソース、フィールド、ヘッダー、またはスコープが追加されても、これらの要素を認識または使用しない既存のクライアントには影響しません。

後方互換性のある変更の詳細については、製品ライフサイクルステージに記載されている Auth0 の API 変更ガイドラインを参照してください。

​

後方互換性のない破壊的変更

後方互換性のない変更は、Auth0 プラットフォームと顧客アプリケーションの相互運用性を変化させることで、不具合を引き起こす可能性があります。そのような変更が必要な場合は、顧客がテナント実装を調整できるよう、事前通知とサポートを提供するために 非推奨化および移行プロセス に従います。

破壊的変更の例には、次のようなものがあります。

• API リソースの削除: API リソースが削除または名前変更されると、そのリソースに依存するクライアントで破壊的変更が発生します。
• URI 構造の変更: 既存の URI の構造を変更すると、それに依存するクライアントに支障が生じる可能性があります。
• メソッド、パラメーター、またはフィールドの削除: メソッド、パラメーター、またはフィールドが削除または名前変更されると、これらの要素を使用しているクライアントにとって破壊的変更となります。
• デフォルト値の変更: フィールドのデフォルト値を変更すると、既存の統合に影響を及ぼし、破壊的変更に該当する場合があります。
• エラーレスポンスおよびステータスコードの変更: エラーレスポンスの形式、エラーコード、またはステータスコードを変更すると、既存のクライアントの動作が損なわれる可能性があります。
• JWT 形式: トークンの JWT 形式の変更は、破壊的変更に該当します。
• JSON 形式: JSON 値の型の変更は、破壊的変更です。

破壊的変更がある場合は、必ず非推奨化プロセスが開始され、顧客に通知したうえで、新しい動作へ移行するための期間として少なくとも 6 か月が提供されます。詳細については、非推奨化およびサポート終了プロセス を参照してください。

​

Auth0 の取り組み

Auth0 は、後方互換性のない変更による影響を、次のプロセスによって最小限に抑えています。

• 非推奨の告知: Auth0 は、予定されている変更についてお客様に事前に通知するため、非推奨を告知します。
• 移行期間: お客様には、更新後の機能へ移行するための最低 6 か月の猶予期間が設けられ、移行プロセスでガイダンスが提供されます。
• サポート終了: 移行期間が終了すると、非推奨となった機能はサポート終了段階に移行し、以後は利用できなくなります。

​

文書化されていない API

文書化されていない Auth0 API は非公開と見なされ、予告なく変更される可能性があります。これらの API は非推奨化プロセスの対象外であるため、本番環境のシステムでの利用を前提にしないでください。