パスワードレス・サインイン・エクスペリエンスをセットアップする

サインアッププロセスを迅速化し、セキュリティを向上させるには、ユーザーのパスワードが任意のエクスペリエンス、またはパスワードレスエクスペリエンスを作成します。

パスワードは、セキュリティ侵害の一般的な原因です。パスワードを任意または無効にすることで、所有ベースのAuthenticatorまたは生体認証の使用をユーザーに求めることができます。セルフサービス登録時にパスワードのセットアップが必要なくなることで、登録を諦めるユーザーの数を減らすことができます。

Authenticator登録ポリシーで、パスワードを任意または無効にするグループを指定します。これらのグループのユーザーは、パスワードをセットアップすることなくorgに登録や認証できます。

開始する前に

  • ユーザーを作成するか、セルフサービス登録を使って登録させます。LDAPユーザーはサポートされません。
  • パスワードレスユーザーに従来のRADIUS認証を使用することはできません。RADIUS認証では、プライマリ認証メカニズムとしてパスワードが使用されます。アプリケーション設定プロパティのOktaでプライマリ認証を実施（Okta performs primary authentication）をクリアした後であれば、RADIUS認証のその他の要素を使用できます。OktaのRADIUSアプリケーション（2FA Only (Passwordless Mode)）の二要素認証のみ（パスワードレスモード）を参照してください。
  • この機能を無効にすると、登録済みパスワードを持たないユーザーはシームレスにロールバックされません。代わりに移行が必要になります。パスワードレスユーザーがいる場合は、この機能を無効にする前にサポートまでお問い合わせください。

パスワードレスのセルフサービス登録

orgに存在しないユーザーがセルフサービスで登録した場合は、プロファイル登録ポリシーで指定したグループに追加されます。これらのユーザーにパスワードが必要であるかどうかは、これらのグループに対応するAuthenticator登録ポリシーによって決まります。

ポリシーによって求められる場合、ユーザーはパスワードを登録する必要があります。パスワードがオプションまたは無効にセットアップされている場合、ユーザーはパスワードを登録することなくサインアップできます。ただし、ポリシーによって求められるその他のAuthenticatorには登録する必要があります。

管理者が作成するユーザーのパスワードレス認証

Authenticatorを登録することなくユーザーを作成した場合、ユーザーはアクティベーションメールを受信します。このメールには、アカウントのアクティブ化とorgへの認証に利用できるマジックリンクが含まれます。作成されるユーザーのステータスは、ユーザーアクション保留中（Pending user action）となります。

ユーザーを作成してパスワードを設定する、またはYubiKeyを登録すると、ユーザーはアクティブ（Active）に設定されます。この場合、ユーザーはアクティベーションメールを受信しません。ユーザーは、登録済みのAuthenticatorを使って自分のorgに直接サインインできます。

ユーザーにパスワードが必要かどうかを決定するには、ディレクトリ（Directory） > ユーザー（People）に移動します。ユーザーアカウントのステータスは、次のいずれかとなります。

  • パスワードの期限切れ（Password expired）：ユーザーはパスワードを必要とし、管理者がパスワードを提供します。ユーザーは、初めてサインインするときに、管理者が提供するパスワードを変更する必要があります。
  • ユーザーアクション保留中（Pending user action）：ユーザーには管理者が登録したAuthenticatorがありません。ユーザーはアクティベーションメールを受信します。
  • アクティブ（Active）：ユーザーはパスワードまたはYubiKeyを必要とし、管理者がこれを提供します。または、ユーザーはパスワードを必要とせず、管理者はパスワードを提供しません。
  • ［Pending user action. User password selection required（ユーザーアクション保留中。ユーザーのパスワード選択が必要です］：別のorgから同期されるパスワードレスユーザーは、このステータスになる可能性があります。これらのユーザーはアクティベーションメールを受信します。グループメンバーシップとAuthenticator登録ポリシーが求める場合は、パスワードの登録が必要になる可能性があります。

ベストプラクティス

管理者がパスワードを使用できることを確認する

  1. 管理者用に別のグループを作成します。
  2. このグループ用に、別のAuthenticator登録、グローバルセッション、アプリ・サインイン・ポリシーを作成します。
  3. グループのAuthenticator登録ポリシーに最高の優先順位を設定します。Authenticator登録ポリシーのリストの最上位（番号1）までドラッグします。

意図したユーザーのみがパスワードレスでサインインできるようにする

  1. パスワードレスユーザー用に別のグループを作成します。
  2. このグループ用に、別のAuthenticator登録、グローバルセッション、アプリ・サインイン・ポリシーを作成します。
  3. グループのAuthenticator登録ポリシーに2番目の優先順位を設定します。Authenticator登録ポリシーのリストで、デフォルトポリシーのすぐ上の位置までドラッグします。これにより、パスワードレスユーザーは、そのためのAuthenticator登録ポリシーの対象となり、デフォルトポリシーの適用対象から外れます。
  4. デフォルトポリシーがパスワードをAuthenticatorとして必要とすることを確認します。
  5. メインの管理者アカウントを、パスワードレスポリシーから明示的に除外します。

この手順を開始する

ポリシーを構成してパスワードを任意または無効に設定します。その上で、パスワードを必要としないユーザーを作成します。パスワードを使用する既存のユーザーからパスワード要件を削除することもできます。

ポリシーを構成してパスワードを任意または無効に設定する

  1. メールAuthenticatorを構成します。認証と復旧（Authentication and recovery）での使用を設定します。
  2. アプリ・サインイン・ポリシーを作成します。

  3. エンドユーザーがパスワードレスで認証できるように、アプリ・サインイン・ポリシー・ルールを追加します。

    • ユーザーが認証に使用する要素（User must authenticate with）を、任意の1要素タイプまたは任意の2要素タイプのオプションに設定します（明示的にパスワードが必要なものを除く）。
    • 2要素を使用するときは、パスワードをレスユーザー向けのMFAを構成するを参照してください。
    • パスワードレスユーザーのAuthenticatorとしてOkta Verifyを使用するときは、ユーザー検証（User Verification）を必須（Required）に設定します。「Okta Verifyオプションを構成する」を参照してください。
  4. グローバルセッションポリシーを作成します。
  5. グローバルセッションポリシールールを追加して、次を使用してユーザーセッションを確立（Establish the user session with）を 認証ポリシーの要件を満たすために使用される任意の要素（Any factor used to meet the Authentication Policy requirements）に設定します。

  6. Authenticator登録ポリシーを作成します。必要時の認証用に少なくとも1つのAuthenticatorを有効にします。必要に応じてその他のAuthenticatorをセットアップします。

    • パスワードが任意（Optional）または無効（Disabled）に設定されている場合、認証用のスタンドアロンAuthenticatorとしてセキュリティ質問を必須（Required）に設定することはできません。ただし、アカウントの復旧では許可されます。
    • ユーザーによる列挙の防止（User Enumeration Prevention）を有効にしている場合、特定のデバイスからorgに初めてサインインするユーザーには、パスワードまたはメールの入力を求めるサインインプロンプトが表示されます。サインインエクスペリエンスを簡略化するために、セキュリティ（Security） > 一般（General）でこの設定を無効にすることもできます。ただし、パスワードを持たないユーザーは、引き続きAuthenticatorとしてメールを使ってサインインできます。

パスワードが任意またはパスワードレスのユーザーを作成する

  1. Admin Consoleで、ディレクトリ（Directory） > ユーザー（People）に進みます。

  2. ユーザーの追加（Add Person）をクリックします。
  3. ユーザータイプ（User type）を選択するか、デフォルトを受け入れます。Okta Universal Directoryのカスタムユーザータイプを参照してください。
  4. パスワードが任意またはパスワードレスの登録ポリシーに対応するグループにユーザーを割り当てます。
  5. その他のフィールドに入力します。
  6. アクティブ化（Activation）フィールドですぐにアクティブ化（Activate now）を選択します。
  7. パスワード（Password）フィールドでパスワードを設定する（I will set the password）をクリアします。

  8. 保存（Save）をクリックします。

パスワードを使用しているユーザーをパスワードが任意またはパスワードレスのユーザーに移行する

ユーザーのパスワード登録を削除するには、ディレクトリ（Directory） > ユーザー（People）に移動します。ユーザー（person）でパスワードをリセットまたは削除（Reset or remove password） > パスワードを削除（Remove password）に移動します。

ユーザーに適用されるAuthenticator登録ポリシーがパスワードを求める場合、ユーザーのパスワードは削除できません。同様に、該当するすべてのポリシーでユーザーのパスワードが無効化されている場合、ユーザーのパスワードは設定またはリセットできません。

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

パスワードが任意またはパスワードレスのエクスペリエンスを構成すると、ユーザーはパスワードレスでサインインまたは登録できるようになります。

パスワードレスで初めてサインインする

管理者が作成するユーザーは、管理者によるアカウントの作成時にアクティブ化メールを受信しません。メールは、管理者がアカウントの作成時に指定したアドレスに送信されます。ユーザーは、メール内のマジックリンクをクリックするか、OTPを入力してメールアドレスを検証します。ユーザーには、Authenticator登録ポリシーが求めるセキュリティ方式のセットアップが求められます。セキュリティ方式をセットアップすると、orgやリソースにアクセスできるようになります。

パスワードレスでセルフサービス登録する

orgに存在しないユーザーは、メールマジックリンクと任意のパスワードセットアップを使って登録できます。ユーザーは、アプリのサインオンページで名前とメールアドレスを入力します。メールのマジックリンクはこのアドレスに送信されます。ユーザーは、リンクをクリックするか、OTPを入力してメールアドレスを検証します。

Authenticator登録ポリシーで任意のAuthenticatorとしてアプリが構成されている場合、アプリではパスワードの作成が求められます。ユーザーには、ポリシーが求めるセキュリティ方式のセットアップも求められます。セキュリティ方式をセットアップすると、ユーザーが登録されます。

End-User Dashboardでパスワードを削除する

Authenticator登録ポリシーで認められている場合、ユーザーは Okta End-User Dashboard > 設定（Settings）に移動してセキュリティ方式としてのパスワードを削除できます。セキュリティ方式（Security Methods）セクションでパスワード（Password）を選択し、削除（Remove）をクリックします。パスワードは、同じ設定からセットアップし直すことができます。