オプションのAuthenticatorとしてのメール

アップグレード後にメールがオプションのAuthenticatorとしてどのように機能するかについて説明します。

変更の概要 メールAuthenticatorは、認証フローと復旧フローの両方で自動登録されます。これはClassic Engineからの変更であり、Classic Engineでは登録ポリシーで必要な場合に認証フローでのみ使用できます。

自動登録により、ユーザーは次の場合に重複するメール登録チャレンジを受け取らないことが保証されます。

  • 自分のメールアドレスを所有していることがすでに証明されている(セルフサービス登録時に作成されたユーザー)。
  • メールアドレスを所有していることを証明する必要がない(管理者が作成したユーザー)。
管理者のエクスペリエンス

アップグレード後にメールを[Optional(任意)]要素にすることがポリシーによって求められるときは、「メールAuthenticatorの自動登録をスキップする」を参照してください。

それ以外の場合は、アップグレード前にメール要素を[Disabled(無効)]または[Required(必須)]に設定する必要があります。Classic Engineのドキュメント「多要素認証登録ポリシーを構成する」を参照してください。

その上で、ユースケースに基づいてIdentity EngineでメールAuthenticatorの設定を選択します。

  • [Disabled(無効)]:ユーザーのプライマリメールアカウントがOktaによって保護されている場合に推奨されます。認証メールはプライマリメールにのみ送信され、セカンダリメールには送信されません。
  • [Required(必須)]:拡張ワークフォースユースケースとカスタマーアイデンティティおよびアクセス管理(CIAM)ユースケースで推奨されます。 プライマリメールの確認は、これらのアイデンティティの一般的なユースケースです。

メールAuthenticatorのデフォルト値は5分ですが、5分単位で最大30分まで延長できます。一般的に受け入れられているベストプラクティスは10分以内です。期限切れのマジックリンクをクリックしたエンドユーザーは、再度サインインする必要があります。

ユーザーエクスペリエンス オプションのAuthenticatorである場合を除き、メールはAuthenticatorとして自動登録されます。ユーザーがその他の必要Authenticatorに登録されている場合でも、別のポリシーで許可されていれば、Authenticatorとして表示される場合があります。

ユーザーがどのように作成され、パスワードが誰によって設定されたかに応じて、ユーザーは初めてサインインするときに、その他のオプションAuthenticatorへの登録を求められない場合があります。

関連項目 Authenticator登録ポリシーを作成する

Authenticator登録ポリシー