Okta Verifyオプションの構成

Okta VerifyをAuthenticatorとして追加した後で、登録時または認証時にユーザーがOkta Verifyとやりとりする方法を構成します。また、Okta FastPassを有効にすることもできます。

開始する前に

  • 番号チャレンジを使ってプッシュ通知をアクティブ化する場合は、バージョン3.3.0以降のSign-In Widgetを使用します。orgが認証APIを直接呼び出す場合は、コードを更新して番号チャレンジAPIの応答を処理します。「応答の例(3桁の番号検証チャレンジの応答を待機)」を参照してください。
  • インターネットとの間のトラフィックを制限するファイアウォールの内側にユーザーが位置している場合、Okta Verifyのプッシュ通知を受信できない可能性があります。Google Firebase Cloud Messagingとの接続が許可されるように、ファイアウォールのポート5228、5229、5230を開いてください。GoogleのASN 15169のIPブロックリストに含まれるすべてのIPアドレスに対する発信接続を受け入れるようにファイアウォールを構成します。
  • セキュリティ上の理由から、OktaOkta Verifyとそのエンドポイント間のトラフィックの検査や変更を許可していません。SSLプロキシを使用するときは、組織のデフォルトのOktaドメインを検査から除外します。Oktaドメインは、通常は*.okta.comまたは*.oktapreview.comです。Oktaドメインの完全なリストについては、「Okta IPアドレスへのアクセスを許可する」を参照してください。
  • FIPS(連邦情報処理標準)に準拠するデバイスへのアクセスを制限する場合、Androidユーザーは、デバイスがFICAM(Federal Identity, Credential, and Access Management)に準拠するように、デバイスのセキュアPINを有効にする必要があります。これを行わない場合、orgにはアクセスできません。一部のAndroidハードウェアは、FIPSへの準拠を認定されていません。FIPS準拠の必要性に対して、ハードウェアキーストアを使用することのセキュリティ上の意味を考慮してください。

このタスクを開始する

  1. Admin Console[Security(セキュリティ)][Authenticator]に移動します。

  2. [Settings(設定)]タブでOkta Verifyに移動し、[Actions(アクション)] [Edit(編集)]をクリックします。
  3. 設定を構成して保存します。

Settings(設定)

Settings(設定)
登録オプション Okta Verify登録のセキュリティを構成します。
  • [Higher security methods(より高いセキュリティメソッド)]:このオプションを選択すると、ユーザーが登録に利用できるのは次の方式のみとなります。

    • [Same device(同一デバイス)]:ユーザーは、orgのサインインURLを提供することでアプリ内でOkta Verify登録を開始および完了します。

      早期アクセスリリース:より少ない手順と強化されたセキュリティを備えた、速やかな登録エクスペリエンスを使用するには、[Admin Console(管理コンソール)][Settings(設定)][Same-Device Enrollment for Okta FastPass(Okta FastPassの同一デバイス登録)]を有効にします。

    • [Device-to-device bootstrap(デバイスツーデバイスブートストラップ)]:ユーザーは、Bluetoothを使って既存のOkta Verifyアカウントを別のモバイルまたはデスクトップデバイスに追加できます。

  • [Any method(任意の方式)]:このオプションを選択すると、ユーザーは次のどのセキュリティ メソッドでも登録できます。

    • [QR code in browser(ブラウザー内のQRコード)]:ユーザーは、ブラウザーでQRコードをスキャンしてモバイルデバイスでOkta Verifyに登録します。

    • [SMS or email link(SMSまたはメールのリンク)]:ユーザーは、SMSまたはメールで送信されるリンクをクリックすることでモバイルデバイスのOkta Verifyに登録します。

    • [Same device(同一デバイス)]:ユーザーは、orgのサインインURLを提供することでアプリ内でOkta Verify登録を開始および完了します。

    • [Device-to-device bootstrap(デバイスツーデバイスブートストラップ)]:ユーザーは、Bluetoothを使って既存のOkta Verifyアカウントを別のモバイルまたはデスクトップデバイスに追加できます。

検証オプション 認証時にエンドユーザーに求められる認証方式を選択します。どの認証方法を選択しても、ユーザーはそれらすべてに自動的に登録されます。検証オプションは、[Authentication Code(認証コード)][Push Notification(プッシュ通知)][Okta FastPass]として[Okta Verify Account Details(Okta Verifyアカウントの詳細)]ページに表示されます。
  • [TOTP (on by default) (Android and iOS only)(TOTP(デフォルトでオン)(AndroidおよびiOSのみ))]:ユーザーは、Okta Verifyが生成する6桁のコードを入力して認証を行います。

  • [Push notification (Android and iOS only)(プッシュ通知)(AndroidおよびiOSのみ))]:ユーザーは、モバイルデバイスにプッシュされた通知をタップして認証を行います。

  • [Okta FastPass (All platforms)(Okta FastPass(すべてのプラットフォーム))]Okta FastPassを有効化します。ユーザーは、[Use Okta FastPass(Okta FastPassを使用する)]をタップまたはクリックして認証を行います。「Okta FastPassを有効にする」を参照してください。

Okta FastPass このセクションは、[Okta FastPass (All platforms)(Okta FastPass(すべてのプラットフォーム))]を選択した場合に表示されます。

Show the "Sign in with Okta FastPass" button([Sign in with Okta FastPass]ボタンを表示する)Sign-In Widget[Sign in with Okta FastPass(Okta FastPassでサインインする)]ボタンを表示するには、このチェックボックスを選択します。このチェックボックスは、デフォルトでは選択されていません。このオプションを選択しない場合、Okta FastPassが有効でもこのサインイン方式はユーザーに表示されません。Okta FastPassを段階的にユーザーにデプロイする場合は、この設定をオフのままにします。

[Device passcode or biometric user verification(デバイスパスコードまたは生体認証によるユーザー検証)]

Okta VerifyまたはOkta FastPassへのユーザーの登録方法を定義します。ユーザー検証はデバイスモデルとオペレーティングシステムによって異なる場合があります。構成がユーザーエクスペリエンスに与える影響を理解するには、「Okta Verifyユーザー検証設定に基づくユーザーエクスペリエンス」を参照してください。
  • [Preferred(推奨)]:ユーザーは、登録時または登録後にデバイスパスコードまたは生体認証確認を有効にすることができます。ユーザーは、生体認証機能をサポートしないデバイスを登録できます。

  • [Required(必須)]:新規ユーザーは、Okta Verifyに登録するときにデバイスパスコードまたは生体認証を設定するよう求められます。デバイスで生体認証がサポートされない場合、ユーザーは代わりにデバイスパスコードを有効にすることができます。この手順をスキップした登録済みユーザーは、登録済みデバイスのOkta Verifyを使って次にサインインを試みると、デバイスパスコードまたは生体認証の有効化を求められます。

    Okta FastPassによる認証時に、ユーザーには本人確認に生体認証を使用するオプションと、デバイスパスコードを使用するオプションがあります。

  • [Required with biometrics only(生体認証でのみ必須)]:新規ユーザーは、Okta Verifyへの登録時に生体認証のセットアップを求められます。デバイスで生体認証がサポートされない場合、ユーザーはOkta Verifyに登録することも、Okta Verifyを使って認証することもできません。この手順をスキップした登録済みユーザーは、登録済みデバイスのOkta Verifyを使って次回サインインを試みたときに生体認証を有効にするよう求められます。

プッシュ通知(番号チャレンジ) Okta Verifyプッシュ通知に番号チャレンジを含めるかどうかを選択します。番号チャレンジは、Oktaが保護するアプリへのサインイン試行が、権限のない人物からのものではなく、意図されたユーザーからのものであることを検証します。番号チャレンジでは、番号はSign-In Widgetに提示され、通知はユーザーのモバイルデバイスのOkta Verifyにプッシュされます。ユーザーは、Sign-In Widgetに提示された番号と一致する番号を選択します。選択が正しければ、ユーザーは保護されたアプリにアクセスできます。番号チャレンジは、ユーザーがOkta Verifyと、サインイン試行を開始するデバイスの両方を所有していることを確認することでフィッシングを防止するのに役立ちます。次のエンドユーザー向けドキュメントを参照してください:「Okta Verify Push通知を使用したサインイン(iOS)」または「Okta Verify Push通知を使用したサインイン(Android)」
  • [Never(使用しない)]:認証試行のリスクレベルに関係なく、ユーザーは番号チャレンジを受信しません。

  • [Only for high risk sign-in attempts(高リスクのサインイン試行に対してのみ)]: ユーザーは、サインイン試行が高リスクとみなされる場合にのみ番号チャレンジを受信します。サインオンポリシールールを構成します。「リスクスコアリングについて」を参照してください。

  • [All push challenges(すべてのプッシュチャレンジ)]:ユーザーは、リスクレベルに関係なく、すべてのOkta Verifyプッシュ通知で番号チャレンジを受信します。

FIPS準拠 Okta Verify登録をFIPS準拠のAndroidまたはiOSデバイスに制限します。このオプションを有効にした場合、Okta Verifyはすべてのセキュリティ操作にFIPS 140-2検証を使用します。また、OktaはFIPSの検証済みベンダーを使用しているため、FedRAMP FICAM要件も満たしています。
  • [FIPS-compliant devices only(FIPS準拠デバイスのみ)]:ユーザーは、Okta VerifyにFIPS準拠デバイスのみを登録できます。

  • [Any device(任意のデバイス)]:ユーザーは、Okta Verifyに任意のデバイスを登録できます。

リスクスコアリングについて

番号チャレンジとOktaのリスクスコアリングを組み合わせることで、Okta orgへのサインインフローのセキュリティを向上させることができます。Oktaは、デバイスの詳細やデバイスの場所など、複数の条件に基づいてリスクを評価します。リスクスコアリングを有効にすると、Oktaへのサインイン試行のたびにリスクレベルが割り当てられ、管理者は、サインイン試行のリスクレベルに基づいて異なるアクションを実行するサインオンポリシールールを構成できます(サインインが高リスクと見なされた場合に多要素認証のプロンプトを表示するなど)。手順については、「リスクスコアリング」を参照してください。

既知の制限

  • Apple Watchでは、生体認証による認証はサポートされません。
  • Androidデバイスの場合、Googleによってクラス3-強に分類された生体認証方法(顔認識および指紋認識)のみがサポートされています。
  • Okta Verifyがワークプロファイルにインストールされている場合、Android 12で生体認証はサポートされません。エンドユーザーに「Keystore not initialized(キーストアが初期化されていません)」というエラーが表示され、生体認証を有効にできません。影響を受けるユーザーのブロックを解除するには、[User Verification(ユーザー検証)][Preferred(推奨)]に設定してから、生体認証の有効化の手順を省略するようにエンドユーザーに伝えてください。
  • LDAPiおよびRADIUS統合では、番号チャレンジを伴うプッシュ通知はサポートされません。この場合は、Okta Verify以外のMFA Authenticatorを構成します。
  • ループバック(localhost)に対してHSTS(HTTP Strict Transport Security)が有効になっている場合、Okta Verify認証は正しく機能しません。ウェブサイトの開発、ホスティング、デバッグをローカルで行うユーザーの多くは、このオプションを有効にします。セキュリティ上の理由から組織がHSTSを必須としないときは、HSTSを必須とするドメインのリストからOkta URLを削除するようユーザーに伝えてください。ブラウザーのドキュメントで手順を確認し、それをユーザーと共有します。

次の手順

認証登録ポリシーにOkta Verifyを登録する」の手順に進みます。

関連項目

Okta Verify Authenticatorの構成

Authenticator登録ポリシーを作成する

Authenticator登録ポリシールールを構成する