複数のID

IDは、サインイン時にユーザーがユーザー名の代わりに入力できる属性です。これらは、認証、復旧、ロック解除のフローで機能し、プロファイル登録フォームに追加されていれば、セルフサービス登録フローでも機能します。Oktaユーザープロファイルで2つの一意のカスタム属性を選択することで、IDとして機能させることができます。ただし、それらの属性は読み取り/書き込み可能（または読み取り専用）で、機密性がなく、データタイプが文字列である必要があります。

ユースケース

IDは標準の認証フローで使用できますが、ハブアンドスポーク組織や連携認証を使用する組織で特に有用です。次のシナリオを検討してください。

ユーザーは、企業org（ハブ）と専門の事業部門（スポーク）の両方のディレクトリに存在します。認証には事業部門のユーザー名を使用しますが、企業orgの従業員番号を使用します。ユーザーがどちらのIDでもハブとスポークにサインインできるように、これら両方の方式をIDとして構成します。

アプリを通じてユーザーがorgへのアクセスを試みると、認証のためにOktaにリダイレクトされます。アプリのサインインページでOktaとは異なる属性が求められる場合、両方をIDとして構成できます。

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

ハブアンドスポークフローでは、ユーザーはハブorgのサインインページにアクセスします。構成済みのいずれかのIDの入力が求められます。このフローではスポークorgはIDプロバイダーとして機能するため、入力フィールドにはその優先IDを入力する必要があります。異なるIDで同じ属性を持つ可能性があるユーザーが正しく認証されるように、Oktaは優先順位の設定に従ってエントリを評価します。

標準の認証フローでは、ユーザーはアプリのサインインページにアクセスすると、構成済みのいずれかのIDを使って認証することが求められます。ハブアンドスポークフローの場合と同様に、Oktaは優先順位の設定に従ってエントリを評価します。

複数のIDによってアプリのMFA要件やサインインフローのシーケンスは変更されないことに注意してください。グローバルセッションおよび認証ポリシーに構成する設定は、IDとパスワードのどちらの入力を最初にユーザーに求めるかを決定します。「サインインフロー」を参照してください。

構成タスク

IDは、ユーザープロファイルポリシーにアプリレベルで構成されます。つまり、org全体を対象に設定することはできませんが、同じユーザープロファイルポリシーをorg内のすべてまたは複数のアプリに適用することができます。このワークフローに従ってIDをセットアップし、その仕組みをユーザーが理解できるようにします。

APIを使って複数のIDを構成することもできます。