Okta Verifyオプションの構成

Okta Verifyをオーセンティケーターとして追加した後で、認証時にエンドユーザーがOkta Verifyとやりとりする方法を制御できるオプションを構成します。また、Okta FastPassを有効にすることもできます。

開始する前に

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

このタスクを開始する

Okta Admin Consoleで、［Security（セキュリティ）］>［Authenticators（オーセンティケーター）］に移動します。
［Setup（セットアップ）］タブで、Okta Verifyに移動し、［Actions（アクション）］>［Edit（編集）］をクリックします。

［Verification options（検証オプション）］セクションで、認証時にエンドユーザーに対して表示される認証方法を選択します。

［TOTP（時間ベースのワンタイムパスワード）］（デフォルトでオン）（AndroidおよびiOSのみ）	ユーザーは、認証の試行時にOkta Verifyによって生成された6桁のコードを入力して、本人確認を行います。
［Push notification（プッシュ通知）］（AndroidおよびiOSのみ）	ユーザーは、認証の試行時にモバイルデバイスにプッシュされる通知をタップして、本人確認を行います。
［Okta FastPass］（すべてのプラットフォーム）	すべてのプラットフォームでOkta FastPassを有効にするには、このオプションを選択します。ユーザーは、アプリにアクセスしようとしたときに表示される［Use Okta Verify on this device（このデバイスでOkta Verifyを使用する）］ボタンをタップまたはクリックして、本人確認を行います。「Okta FastPassを構成する」を参照してください。

どの検証オプションを選択しても、エンドユーザーはそれらすべてに自動的に登録されます。検証オプションは、アプリの［Account Details（アカウントの詳細）］ページに、［Authentication Code（認証コード）］、［Push Notification（プッシュ通知）］、および［Okta FastPass］として表示されます。

ユーザーをすべての認証方法に自動的に登録しますが、認証時に表示される認証方法を制御できるようにすることで、ユーザーエクスペリエンスを簡素化できます。認証方法は後から追加/削除できます。

［Okta FastPass (All platforms)（Okta FastPass（すべてのプラットフォーム））］オプションを選択すると、［Okta FastPass］セクションが表示されます。

［Show the "Sign in with Okta FastPass " button（「Okta FastPassを使用してサインインする」ボタンを表示）］

Okta Sign-in Widgetに［Sign in with Okta FastPass（Okta FastPassを使用してサインインする）］ボタンを表示するには、このチェックボックスを選択します。

デフォルトでは、このチェックボックスは選択されていません。Okta FastPassが有効であっても、このサインイン方法はエンドユーザーに表示されません。Okta FastPassをユーザーに段階的にデプロイする場合は、このチェックボックスをオフのままにすることを検討してください。

［User verification（ユーザー検証）］リストで、Okta Verifyでの認証時に生体認証を推奨するか、必須にするかを選択します。

［Preferred（推奨）］

ユーザーは、登録時または登録後に生体認証を有効にすることができます。ユーザーは、生体認証機能をサポートしていないデバイスを登録できます。

［Required（必須）］

ユーザーは、Okta Verifyアカウントを作成するとき、または登録済みデバイスでOkta Verifyを使用して次回サインインしようとするときに生体認証を設定するよう求められます。デバイスで生体認証がサポートされていない場合、ユーザーはOkta Verifyアカウントを設定することも、Okta Verifyで認証することもできません。

生体認証を設定したら、ユーザーがOkta Verifyプッシュ通知でサインインするたびに生体認証プロンプトが表示されるようになります。

［Push notification: number challenge（プッシュ通知：番号チャレンジ）］セクションで、Okta Verifyプッシュチャレンジに番号チャレンジを含めるかどうかを選択するオプションを選択します。

番号チャレンジは、未許可のユーザーではなく、許可されたユーザーが保護されたアプリにサインインを試みていることを検証します。番号チャレンジでは、サインイン手順で番号が提示され、ユーザーのモバイルデバイスのOkta Verifyに通知がプッシュされます。ユーザーは、サインイン手順で提示された番号と一致する番号をモバイルデバイスのOkta Verifyで選択します。これにより、保護されたアプリへのアクセスが許可されます。

番号チャレンジは、ユーザーがOkta Verifyと、サインイン試行を開始するデバイスの両方を所有していることを確認することでフィッシングを防止するのに役立ちます。

［Never（行わない）］	認証試行のリスクレベルに関係なく、ユーザーには番号チャレンジが表示されません。
［Only for high risk sign-in attempts（高リスクのサインイン試行の場合のみ）］	番号チャレンジは、サインイン試行が特定レベルのリスク（高リスクなど）として評価される場合にのみユーザーに提示できます。管理者はサインオンポリシールールの設定を構成する必要があります。「リスクスコアリングについて」を参照してください。
［All push challenges（すべてのプッシュチャレンジ）］	リスクレベルに関係なく、すべてのOkta Verifyプッシュチャレンジでユーザーに番号チャレンジが提示されます。［All push challenges（すべてのプッシュチャレンジ）］オプションを選択すると、Okta Identity Engineで作成されたユーザーに対してAndroidバージョン6.1.1向けのOkta Verifyがクラッシュします。こうした場合、ユーザーにはOkta Verifyを最新のバージョンに更新するように推奨してください。

［FIPS Compliance（FIPS準拠）］セクションで、Okta Verifyへの登録を、FIPS準拠のAndroidデバイスまたはiOSデバイスに対してのみ許可するか、すべてのデバイスに対して許可するかを選択します。

FIPS（連邦情報処理標準）は、米国政府が開発した技術要件セットです。政府は、行政機関、企業、Organization向けのコンピューターセキュリティガイドラインを策定しました。

このオプションを有効にした場合、Okta Verifyはすべてのセキュリティ操作にFIPS 140-2検証を使用します。また、OktaはFIPSの検証済みベンダーを使用しているため、FedRAMP FICAM要件も満たしています。

［FIPS compliant devices only（FIPS準拠のデバイスのみ）］	ユーザーはFIPS準拠のデバイスのみをOkta Verifyに登録できます。
［Any device（任意のデバイス）］	ユーザーは任意のデバイスをOkta Verifyに登録できます。

［Save（保存）］をクリックします。

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

［Sign in with Okta FastPass（Okta FastPassを使用してサインインする）］ボタン

ユーザーが［Sign in with Okta FastPass（Okta FastPassを使用してサインインする）］をクリックすると、Okta Verifyを開くように求められます。

プッシュ通知：番号チャレンジ

［Only for high risk sign-in attempts（高リスクのサインイン試行の場合のみ）］または［All push challenges（すべてのプッシュチャレンジ）］オプションを選択した場合：

保護されたリソースにアクセスする場合、Okta Verifyプッシュ通知に登録されているAndroidまたはiOSユーザーは、サインイン手順で［Get a push notification（プッシュ通知を受け取る）］オプションをクリックします。
サインイン手順で番号が表示されます。
モバイルデバイスで、［Review（確認）］オプション付きの通知がOkta Verifyに表示されます。ユーザーは［Review（確認）］をタップし、サインイン手順で提示される番号と一致する番号をデバイスでタップします。検証は、番号が一致する場合にのみ成功します。これにより、ユーザーが未許可のユーザーではなく、サインイン試行を開始したユーザーであることが保証されます。サインイン試行が開始された場所に関する詳細は、番号の選択肢の下に表示されます。オプションとして、［Cancel the sign-in attempt（サインイン試行をキャンセル）］をタップするとサインイン試行を拒否できます。

次のエンドユーザー向けドキュメントを参照してください：「Okta Verifyプッシュ通知を使用したサインイン（iOS）」または「Okta Verifyプッシュ通知を使用したサインイン（Android）」。

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

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

既知の制限

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

次の手順

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