メールオーセンティケーターの構成

メールオーセンティケーターは、ユーザーがアカウントへのアクセスを認証または復旧できるように、以下の2つの方法を提供します。

メールマジックリンクをクリックする。
6桁の検証コードをワンタイムパスワード（OTP）として使用する。

Okta開発者用ドキュメントの「メールマジックリンクの概要」では、メールマジックリンクとOTPの概念、およびそれらの違いについて説明しています。

Oktaはこれらの認証方法を、ユーザーのメインのメールアドレスへのメッセージで送信します。ユーザーがメールにアクセスできることで、サインインを試みたユーザーが意図したユーザーであることが確認されます。

この方式は、ユーザーが認証するための簡単な方法を提供しますが、メールオーセンティケーターを実装する場合に考慮すべき事項がいくつかあります。

ユーザーが所定の時間内にメールマジックリンクをクリックしない、またはOTPを使用しない場合、認証は処理されません。
メールは常に安全なプロトコルで送信されるとは限りません。許可されていない第三者によって、暗号化されていないメッセージが傍受される可能性があります。このようなリスクを減らすため、メールマジックリンクとOTPコードに割り当てるチャレンジの有効期間を短くすることを検討してください。
メールメッセージは、ネットワークの問題によって遅延する可能性があります。チャレンジの有効期間が過ぎた後に認証メールが届いた場合、ユーザーは別の認証メールをリクエストする必要があります。
メールメッセージは、ユーザーの迷惑メールフォルダに届く可能性があります。認証メールが届かない場合は、このフォルダを確認するようにユーザーに通知してください。

メールオーセンティケーターを追加する

リダイレクト（Oktaでホストされた）認証フローと組み込み認証フローの両方で、orgにメールオーセンティケーターを追加する必要があります。

管理コンソールで、［Security（セキュリティ）］［Authenticators（オーセンティケーター）］に移動します。
［Setup（設定）］タブで、［Add Authenticator（オーセンティケーターを追加）］をクリックします。
［Email（メール）］タイルで［Add（追加）］をクリックします。
任意。デフォルトの［Email challenge lifetime (minutes)（メールチャレンジの有効期間（分））］を変更します。
デフォルトの値は5分ですが、5分単位で最大30分まで延長できます。一般的に受け入れられているベストプラクティスは10分以内です。エンドユーザーは、期限切れのマジックリンクをクリックした場合、再度サインインする必要があります。
認証用のメールチャレンジリンクに加えて、Oktaはこの有効期限の値をセルフサービスのパスワードリセットとアカウントのロック解除にも適用します。

このオーセンティケーターをアカウント復旧にのみ使用する、または認証とアカウント復旧の両方に使用するようにOktaを構成できます。復旧オプションのみを選択した場合は、グローバルセッションポリシーの評価中にOktaが認証を要求することはありません。

エンドユーザーがメールオーセンティケーターを使用できるシナリオを選択します：
- 認証と復旧
- 復旧
［Add（追加）］をクリックします。

サインインフローに組み込み認証を使用している場合は、「メールマジックリンクの概要」で説明されているマジックリンクの統合手順に従う必要があります。

エンドユーザーエクスペリエンス

エンドユーザーがサインイン、パスワードのリセット、またはアカウントロック解除を試みると、そのエンドユーザーに対してマジックリンクとワンタイムパスワード（OTP）コードを含むメールが送信されます。エンドユーザー向けドキュメントには、メールマジックリンクまたはワンタイムパスワードを使用してサインインする方法が記載されています。

サインインの試行

エンドユーザーが同じブラウザーでE メールマジックリンクをクリックし、認証フローで後続の要素が要求されない場合、同じブラウザーで新しく開いたタブから自動的にサインインされます。セッションは元のブラウザータブで終了します。

ただし、エンドユーザーが別のブラウザーまたはデバイスでマジックリンクメールを受信または開いた場合、エクスペリエンスは異なります。エンドユーザーは元のブラウザーに戻り、［Enter a verification code instead（代わりに検証コードを入力する）］をクリックする必要があります。次に、OTPコードを入力して検証プロセスを完了できます。

エンドユーザーは認証フローによって検証された後、アプリケーション用に構成された宛先にリダイレクトされます。

エンドユーザーがOktaにサインインしようとした場合、ブラウザーでOkta End-User Dashboardが開きます。
エンドユーザーが組み込みの認証フローを使用してサインインしようとした場合、［Email Verification Experience（メール検証エクスペリエンス）］設定で指定された場所にリダイレクトされます。「アプリ統合の設定を構成する」を参照してください。

パスワードリセット

パスワードリセットの場合、エンドユーザーがメール内のリンクをクリックすると、新しいタブに誘導され、リクエストしたことを確認するよう求められます。リクエストを確認すると、フローは元のブラウザータブで終了し、新しいタブで新しいパスワードを設定できるようになります。パスワードが受け入れ基準を満たしている場合、エンドユーザーは［Back to sign in（サインインに戻る）］をクリックしてサインインページに戻ります。エンドユーザーが［Enter a verification code instead（代わりに検証コードを入力する）］をクリックすると、同じタブで新しいパスワードを設定できます。その後、サインイン・アクションが完了します。

以下のフローは、orgが2022.10.0リリースより後に作成された場合、またはセルフサービス・パスワード・リセット早期アクセス機能をアクティベートした場合に適用されます。

パスワード・リセットの場合、エンドユーザーがメールを受信したのと同じブラウザーを使用してメールマジックリンクをクリックすると、新しいタブが開き、そこで新しいパスワードの入力と確認を求められます。パスワードが受け入れ基準を満たしている場合、エンドユーザーは、同じブラウザーで新しく開いたタブから、新しい資格情報を使用して自動的にサインインします。セッションは元のブラウザータブで終了します。

アカウントのロック解除

アカウントのロックを解除する場合、ユーザーがリンクをクリックすると、新しいブラウザータブが開いて確認を求められます。リクエストを確認すると、フローは新しいブラウザータブで終了し、元のブラウザータブで［Back to sign in（サインインに戻る）］をクリックできるようになります。エンドユーザーが［Enter a verification code instead（代わりに検証コードを入力する）］をクリックし、元のブラウザータブにコードを入力すると、その後ロック解除アクションが完了し、［Back to sign in（サインインに戻る）］をクリックできます。

ただし、エンドユーザーがメールマジックリンクを別のブラウザーまたはデバイスで受信または開いた場合は、元のブラウザーに戻って［Enter a verification code instead（代わりに検証コードを入力する）］をクリックする必要があります。その後、メールで提供されたOTPコードを入力してパスワードをリセットし、検証プロセスを完了できます。

以下のフローは、orgが2022.10.0リリースより後に作成された場合、またはセルフサービスによるアカウント・ロック解除早期アクセス機能をアクティベートした場合に適用されます。

アカウントのロック解除の場合、エンドユーザーがロック解除リクエストを開始したのと同じブラウザーを使用してメールマジックリンクをクリックすると、新しいタブが開き、次の手順に進むよう求められます。エンドユーザーは、ロック解除リクエストで必要なステップアップ操作を完了する必要があります。メールリンクのクリックと、エンドユーザーが完了したすべてのステップアップ検証が、検証基準としてカウントされます。

エンドユーザーがすべての承認基準を満たしている場合、ブラウザーの同じタブでアプリケーションにサインインされます。セッションは元のブラウザータブで終了します。

制限事項

認証メールは常にユーザーのメインのメールアドレスに送信されます。
ユーザーがOkta End-User Dashboardと［Okta End User Settings（Oktaエンドユーザー設定）］ページにアクセスできる場合は、ユーザープロファイルでメインのメールアドレスを読み取り専用属性に設定します。エンドユーザーのメインのメールアドレスを変更すると、そのアドレスは自動的に新しいメールオーセンティケーターに登録され、追加の確認は不要で新しいアドレスにメールが送信されるようになります。
メールオーセンティケーターは、ユーザーが自分のプライマリメールアドレスを確認したとき、またはユーザーアカウントの作成時にプライマリメールアドレスを指定した場合に、認証と復旧の両方のために自動登録されます。これにより、ユーザーがメールアドレスを所有していることをすでに証明済みの場合（セルフサービス登録）、またはメールアドレスを所有していることを証明する必要がない場合（管理者が作成したユーザーアカウント）、ユーザーが不要なメール登録チャレンジを受け取らないことが保証されます。