新規ユーザーの登録、アクティベーション、サインイン・エクスペリエンス
新規ユーザーは、サインイン・ウィジェットでプロファイルを登録してアクティブ化できます。そのため、オンボーディング・エクスペリエンスを完全にカスタマイズし、ブランド化できます。
サインイン・ウィジェットは、組織に設定したポリシーに従い、ユース・ケースによって変わります。
セルフサービス登録
セルフサービス登録が有効になっていて、組織に存在しないユーザー名をエンド・ユーザーが入力した場合、エンド・ユーザーは、アカウントにサインアップして登録するよう求められます。
- エンド・ユーザーはドメインを含む完全なアプリの[ユーザー名]を入力し、[次へ]をクリックします。
- サインイン・ウィジェットに、「このユーザー名のアカウントがありません。 アカウントにサインアップしてください」というメッセージが表示されます。
- エンド・ユーザーは[サインアップ]をクリックし、[アカウント登録の作成]フォームを起動します。
セルフサービス登録が無効になっていて、組織に存在しないユーザー名をエンド・ユーザーが入力した場合、エンド・ユーザーはパスワードの入力を求められますが、サインインは許可されません。このシナリオでは、アカウントにサインアップするオプションは表示されません。
サインイン・フロー
サインイン・フローのシーケンスは、ポリシーで設定した認証アシュアランス要件によって異なります。Identity Engineでは、エンド・ユーザーがアプリにアクセスできるようになる前に、Oktaとアプリのサインオン・ポリシーの両方で指定された認証アシュアランスが満たされている必要があることに注意してください。
サインオン・ポリシーはユーザーが次のステップに進み、アクセスの許可、チャレンジ・プロンプトの表示、別のチャレンジ・プロンプトが表示されるまでの時間の設定など、取るべきアクションを指定するために必要なコンテキストを提供します。Oktaのサインオン・ポリシーでは、すべてのアプリのアクセスをグローバルに定義します。アプリのサインオン・ポリシーは、リクエストされたアプリケーションのコンテキストでエンド・ユーザーの認証を強制します。ユーザーの場所とプロファイルは、ポリシーのグループ・メンバーシップと認証基準の両方と照合して検証されます。
エンド・ユーザーのサインイン・エクスペリエンスについては、次の点に注意してください。
- パスワードなしでのサインインが許可されている場合、Identity Engineはサインイン・エクスペリエンスを最適化します。デバイスがOkta Verifyに登録されていて、生体認証オーセンティケーターが有効になっている場合、ユーザー認証に使用される最初の要素は必ず生体認証オーセンティケーターです。
- アシュアランスによってエンド・ユーザーがパスワードを使用してサインインすることが求められる場合、必ず最初にパスワード・プロンプトが表示されます。これは、アプリ・サインオン・ポリシーとパスワード・オーセンティケーターに加えて、ほかの要素タイプがサインオン・ポリシーで定義されるすべての構成で該当します。
パスワード/IDP/アプリのサインオン・ルールで許可された任意の要素
Oktaサインオン・ポリシー・ルールのいずれかでプライマリ要素がパスワード/IDP/アプリのサインオン・ルールで許可された任意の要素に設定されている場合、ID優先のサインイン・ウィジェットがアクセス・フローの最初の画面としてエンド・ユーザーに表示されます。
- エンド・ユーザーはドメインを含む完全なアプリの[ユーザー名]を入力し、[次へ]をクリックします。[サインインしたままにする]をオンにすると、サインオン・ポリシーで指定された期間にわたって、IDとオーセンティケーターの検証情報がデバイスに保持されます。これは、Classic Engine組織の[記憶する]オプションに代わるものです。
- エンド・ユーザーは[セキュリティー方法]ページで、Oktaサインオン・ポリシーとアプリ・サインオン・ポリシーの両方で許可されているプライマリ・オーセンティケーターを1つ選択します。
- オーセンティケーターを選択した後、エンド・ユーザーは検証ステップに進みます。エンド・ユーザーは必要なオーセンティケーターを指定して、[確認]をクリックします。
パスワード/IDP
Oktaサインオン・ポリシー・ルールのいずれかでプライマリ要素がパスワード/IDPに設定されている場合、パスワード優先のサインイン・ウィジェットがエンド・ユーザーに表示されます。
- エンド・ユーザーはドメインを含む完全なアプリの[ユーザー名]を入力し、[次へ]をクリックします。[サインインしたままにする]をオンにすると、サインオン・ポリシーで指定された期間にわたって、IDとオーセンティケーターの検証情報がデバイスに保持されます。これは、Classic Engine組織の[記憶する]オプションに代わるものです。
- エンド・ユーザーは[パスワード]フィールドにパスワードを入力し、[次へ]をクリックします。
- サインオン・ポリシーのいずれかで2つ目の要素が必要な場合、エンド・ユーザーは[セキュリティー方法]ページで選択します。それから、検証手順を完了します。
サインイン時にユーザーを記憶する
管理者は、[セキュリティー] > [一般] > [組織の設定]で、[サインイン時にユーザーを記憶する]機能を構成できます。[サインイン時にユーザーを記憶する]により、ブラウザー・ウィンドウの有効期間、またはユーザーがCookieを消去するまで、ウィジェットが表示されるたびにサインイン・ウィジェットの[ユーザー名]フィールドが自動的に入力されます。[サインイン時にユーザーを記憶する]では、ユーザーがサインインしたままになったり、多要素認証設定が保存されたりすることはありません。
新しいデバイスでの最初のサインイン試行
新しいデバイスからのサインイン試行はすべて、以下の同じプロセスに従います。
- 組織でSSOにメールを使用している場合、ユーザー・プロファイルが存在しない場合やユーザーがサインインできない場合でも、ユーザーは常にメールおよびパスワードのサインイン・オプションを使用できます。
- 認証エラーが発生するとサインインできません。
- 組織でSSOにメールを使用していない場合、ユーザーは常にパスワードの入力を求められます。
- 同じユーザーが再度ブラウザーからサインインを試みると、使用可能なオーセンティケーターの完全なリストが表示されます。
SSOに使用されるメール
組織でSSOにメールを使用している場合、既存のエンド・ユーザーが新しいデバイスでアプリにアクセスしようとすると、ID優先のサインイン・ウィジェットが表示されます。
- エンド・ユーザーはドメインを含む完全なアプリの[ユーザー名]を入力し、[次へ]をクリックします。
- エンド・ユーザーは[パスワード]フィールドにパスワードを入力し、[次へ]をクリックします。
- サインイン・ウィジェットに誤ったパスワードのエラーが表示されます。
SSOに使用されないメール
組織でSSOにメールを使用していない場合、既存のエンド・ユーザーが新しいデバイスでアプリにアクセスしようとすると、ID優先のサインイン・ウィジェットが表示されます。
- エンド・ユーザーはドメインを含む完全なアプリの[ユーザー名]を入力し、[次へ]をクリックします。[サインインしたままにする]をオンにすると、サインオン・ポリシーで指定された期間にわたって、IDとオーセンティケーターの検証情報がデバイスに保持されます。これは、Classic Engine組織の[記憶する]オプションに代わるものです。
- エンド・ユーザーは[セキュリティー方法]ページで、Oktaサインオン・ポリシーとアプリ・サインオン・ポリシーの両方で許可されているプライマリ・オーセンティケーターを1つ選択します。
- サインイン・ウィジェットにオーセンティケーター・エラーが表示されます。
メールが必須のポリシー要素として構成されている場合、ユーザーはメールに記載されているコードを使用して認証するか、リンクをクリックできます。
- 後続の要素が不要な場合、同じブラウザー・セッションでリンクをクリックする限り、ユーザーは自動的にサインインできます。
- ユーザーが別のブラウザー・セッションで（または完全に別のデバイスで）リンクを開いた場合、サインインする元のブラウザー・セッションに戻るよう求められます。