複数の識別子

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

ユースケース

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

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

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

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

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

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

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

構成タスク

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

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