- 早期かつ頻繁に、顧客からのフィードバックに基づいて繰り返し価値を提供する
- 顧客を深く理解しようと努力し、あらゆる決定で顧客を念頭に置いて考える
- データを絶え間なく取得して分析し、より良い選択ができるようにする
- 機能の追加では、製品全体の現在、理想、未来のバージョンを思い描きながら設計する
| トピック | 説明 |
|---|---|
| 製品のリリース段階 | Auth0がどのように製品機能の開発、発表と廃止を行うのか説明します。 |
| 移行プロセス | Auth0の廃止と移行のプロセスについて説明します。 |
| 廃止と移行 | 現在の廃止機能と新しい動作や機能への移行方法について説明します。 |
| これまでの移行 | これまでに提供してきた移行について説明します。 |
| トピック | 説明 |
|---|---|
| 製品のリリース段階 | Auth0がどのように製品機能の開発、発表と廃止を行うのか説明します。 |
| 移行プロセス | Auth0の廃止と移行のプロセスについて説明します。 |
| 廃止と移行 | 現在の廃止機能と新しい動作や機能への移行方法について説明します。 |
| これまでの移行 | これまでに提供してきた移行について説明します。 |
Auth0 API
Auth0はAuthentication APIやなどのAPIを公開して維持し、それぞれにはAPIの仕様や関連アーティファクトを基に、Auth0と顧客間の契約が定義されています。Auth0はIETFやOIDCなどの機関による規格に従っており、それらの規格は標準が存在しない中で広く認知されています。また、ベストプラクティスを忠実に守って専用のAPIを開発しています。 これらのAPIに対する変更は、後方互換や後方非互換にかかわらず、機能性や安全性、または性能の理由から時には必要になります。後方互換性のある非破壊的な変更
後方互換性のある変更は、Auth0プラットフォームと顧客のアプリケーション間の動作を中断しないため、顧客には即座の対応や移行プロセスが必要ありません。 非破壊的な変更の例には以下が含まれます。- 不透明な文字列 ：不透明な文字列（トークンやIDなど）の形式やサイズが変更されることがあります。クライアントは固定のサイズや形式を想定してはいけません。不透明な文字列の最大サイズが4096文字を超えることはありません。
- のサイズ ：の仕様（RFC6749）はJWT資格情報のサイズを定義していません。Auth0が発行するJWTはサイズが一様でない可能性があるため、クライアントは特定のサイズを想定してはいけません。
- 認可コードのサイズ ：OAuthの仕様に従って、クライアントは認可コードのサイズが一様ではないことを予期しなければなりません。
- 認識されない応答パラメーター ：クライアントは認識されない応答パラメーターを無視しなければなりません。そうすることで、Auth0は現在の機能性に影響を与えることなく、新しい機能を追加することができます。
- 新しいリソース、フィールド、ヘッダーまたはスコープ ：新しいAPIリソース、フィールド、ヘッダーまたはスコープの追加は、それらの要素を認識または使用しない既存のクライアントには影響しません。
後方非互換の破壊的な変更
後方非互換の変更は、Auth0プラットフォームと顧客のアプリケーション間の動作を変えてしまうため、失敗の原因となる可能性があります。そのような変更が必要な場合には、廃止と移行のプロセスに従って、顧客がテナントの実装を調整できるように通知とサポートを提供します。 破壊的な変更の例には以下が含まれます。- APIリソースの削除 ：APIリソースの削除や名前の変更があった場合には、そのリソースを使用しているクライアントにとって非互換の変更になります。
- URI構造の変更 ：既存のURIの構造を変更することは、それに依存するクライアントの動作を妨げます。
- メソッド、パラメーターまたはフィールドの削除 ：メソッド、パラメーターまたはフィールドの削除や名前の変更があった場合には、それらの要素を使用しているクライアントにとって非互換の変更になります。
- デフォルト値の変更 ：フィールドのデフォルト値を変更すると、既存の統合に影響を与えるため、非互換の変更になります。
- エラー応答やステータスコードの変更 ：エラー応答の形式、エラーコード、ステータスコードを変更すると、既存のクライアントが動作しなくなる可能性があります。
- JWTの形式 ：トークンのJWT形式を変更することは非互換の変更です。
- JSONの形式 ：JSON値のタイプを変更することは非互換の変更です。
Auth0の取り組み
後方非互換の変更による弊害を最小限に抑えるために、Auth0は以下のプロセスを行います。- 廃止の告知 ：Auth0は廃止を告知して、顧客に変更の予定を通知します。
- 移行の期間 ：顧客には、移行プロセスのガイダンスと共に、更新された機能性への移行に少なくとも6ヵ月の猶予が提供されます。
- サポート終了（EOL） ：移行の期間が終了すると、廃止された機能がサポート終了段階へ進み、利用できなくなります。