アップグレードのカスタマイズを準備する

セルフサービスアップグレードを行う前に、すべてのカスタマイズを評価します。Identity Engineにアップグレードすると、Classic Engineで構成するカスタムサインインページが機能しなくなる場合があります。

OIEアップグレードハブは、サインインエクスペリエンスのカスタマイズを検出した場合に確認アイテムを表示します。これは、カスタマイズに問題（UI文字列の変更がカスタマイズである場合など）があることを意味しません。カスタマイズ確認アイテムが表示されるときは、Okta org内でそれを特定して準備手順に従います。

はじめに

Okta認証エクスペリエンスを実装するためにorgが使用するデプロイメントモデルを決定します。

リダイレクト：ユーザーは認証のためにアプリからOktaがホスティングするSign-In Widgetにリダイレクトされます。認証が完了すると、ユーザーは再びアプリにリダイレクトされます。リダイレクトモデルの準備は簡単です。

代わりに、お客様がホスティングするSign-In Widgetまたはサーバー側のコードを使ってAPIが認証フローを仲介します。orgがSign-In Widgetをホスティングしている場合、アップグレードの準備は比較的簡単です。APIまたはSDKを使用する場合、準備はさらに複雑になります。

複数のブランドを擁するorgでは、ブランドごとに異なるデプロイメントモデルが使用される場合があります。各モデルの準備方法については、次のシナリオを参照してください。

OktaがホスティングするSign-In Widget（デフォルト）

orgのサインインURLにokta.comまたはoktapreview.comが含まれていれば、OktaがホスティングするSign-In Widgetを使用しています。これがデフォルトの構成であり、カスタマイズはありません。変更は不要です。

OktaがホスティングするSign-In Widgetとカスタムドメイン

カスタムドメインがあるorgは、OktaがホスティングするSign-In Widgetを使用しますが、サインインURLにokta.comまたはoktapreview.comは含まれません。Sign-In Widgetでカスタマイズを特定してテストするには、次の手順を完了します。

Admin Consoleで［Customizations（カスタマイズ）］［Brands（ブランド）］に移動します。
カスタムドメインがあるブランドを選択し、［ページ］タブを選択します。
［サインインページ］パネルで［Configure（構成）］をクリックします。
コードエディターで廃止されたJavaScriptメソッドを探します。見つかったときは、ガイドで推奨される変更を加えます。
カスタムCSSスクリプトまたは変更された言語を探します。見つかったときは、コードをコピーしてIdentity Engine orgのコードエディターに貼り付けることでテストできます。

問題が解決したら、Sign-In Widgetのバージョンをアップグレードしてテストに進むことができます。

Sign-In Widgetをアップグレードします。
アプリでサインインフローをテストし、更新後のSign-In Widgetが想定どおりに機能することを確認します。

お客様がホスティングするSign-In Widget

OIEアップグレードハブは、組み込まれたSign-In Widgetを検出した場合に確認アイテムを表示します。Sign-In Widgetが組み込まれている場所を特定するには、次の手順を完了します。

Admin Consoleで［Security（セキュリティ）］［API］に移動します。
［信頼済みオリジン］タブを開きます。
CORSでリストタイプをフィルタリングします。
CORS向けに登録されている各URLを調べます。CORSはクライアント側の認証フローの要件であるため（たとえば、Sign-In WidgetまたはJavaScript AuthJS SDK）、表示されるURLは、いずれも実装である可能性があります。

Sign-In Widgetが組み込まれていることを識別したら、そのバージョンをアップグレードしてテストに進むことができます。

Sign-In Widgetをアップグレードします。
アプリでサインインフローをテストし、更新後のSign-In Widgetが想定どおりに機能することを確認します。
サインインページのスタイルを設定し、i18nプロパティを更新します。
「デプロイメントモデル - 組み込まれたOkta Sign-In Widget」をレビューします。

お客様がホスティングするSDKまたはカスタムサインインページとサーバー側のコード

アップグレードする前に別のデプロイメントモデルに切り替えることをお勧めします。Identity Engineは、ホスティングされたSDKまたはサーバー側コードの必要性を少なくする高度なブランディング、インラインフック、イベントフックを提供します。

これは最も複雑なシナリオです。OIEアップグレードハブは、組み込み実装やサーバー側実装の確認アイテムを常に表示するとは限りません（現時点ではセッションAPIの使用に制限されています）。アップグレードの前に、開発者と協力してカスタム認証または復旧フローを扱うすべてのチームがコードをテストできることを確認します。次の手順は、コードが存在する場所を識別する上で役立ちます。

Admin Consoleで、［Reports（レポート）］［System Log（システムログ）］に移動します。
［Search（検索）］フィールドに次のクエリを入力します。
client.userAgent.rawUserAgent pr and (debugContext.debugData.requestUri sw "/api/v1/authn" or debugContext.debugData.requestUri sw "/api/v1/sessions" or debugContext.debugData.requestUri sw "/api/v1/factors")
結果をCSVとしてダウンロードします。
一般的なブラウザー以外のraw.UserAgent値をCSVで検索します。
信頼できるアプリケーションAPIトークン（System.Transaction.Detail.RequestApiToken）をSystem Logで検索します。

Sign-In Widgetが組み込まれている場所を識別したら、開発者と協力してアップグレードを準備します。