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

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

OIEアップグレードハブ（OIE Upgrade Hub）は、サインインエクスペリエンスのカスタマイズを検出した場合に確認アイテムを表示します。これは、カスタマイズに問題（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 でカスタマイズを特定してテストするには、次の手順を完了します。

  1. Admin Consoleでカスタマイズ（Customizations） > ブランド（Brands）に移動します。

  2. カスタムドメインがあるブランドを選択し、ページ（Pages）タブを選択します。
  3. サインインページ（Sign-in page）パネルで構成（Configure）をクリックします。
  4. コードエディター（Code editor）で廃止されたJavaScriptメソッドを探します。見つかったときは、ガイドで推奨される変更を加えます。
  5. カスタムCSSスクリプトまたは変更された言語を探します。見つかったときは、コードをコピーしてIdentity Engine orgのコードエディターに貼り付けることでテストできます。

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

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

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

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

  1. Admin Consoleで、セキュリティ（Security） > APIに移動します。

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

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

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

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

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

  1. Admin Consoleでレポート（Reports） > システムログ（System Log）に移動します。

  2. 検索（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")

  3. 結果をCSVとしてダウンロードします。
  4. 一般的なブラウザー以外のraw.UserAgent値をCSVで検索します。
  5. 信頼できるアプリケーションAPIトークン（System.Transaction.Detail.RequestApiToken）をシステムログで検索します。

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

関連項目

Identity Engine用のウィジェット構成への変更

Classic Engineエクスペリエンスを記録する

Okta Sign-In Widget