データベースへの保存にAWS Cognitoの「ユーザー名」または「サブ」（uid）を使用する必要がありますか？
AWS Cognitoサービスに認証されたユーザーがいて、彼の一意の識別子をデータベースに保存したいと考えています。ユーザーのユーザー名（電話番号）または「サブ」（ユーザーのuid）を保存する必要がありますか？ AdminGetUser のようなすべてのAmazon API関数は「username」パラメーターを使用していますが、sub/uidは使用していません。
しかし、私は article も読み、作者は「ユーザー名は再割り当て可能であるため、「username」ではなく「sub」クレームの値に関するポリシーを常に生成します。Subは決して再割り当てされないユーザーのUUIDです別のユーザーに」
だから、今私は一意のユーザー識別子として使用する必要があるものをためらっています-「ユーザー名」または「サブ」
ありがとうございました。
sub属性を使用する必要があります。実際、ユーザー名Ericoのユーザーが自分のアカウントを削除した場合、新しいユーザーが後でこの同じユーザー名を使用でき、マッピングが正しくなくなります...
ユーザー名は、ユーザーの登録に常に必要であり、ユーザーの作成後に変更することはできません。
しかしながら
ユーザー名はユーザープール内で一意である必要があります。ユーザー名は再利用できますが、ユーザー名が削除されて使用されなくなった後でのみ使用できます。
更新
データベースでは、subをIDとして、usernameを属性として使用できます。これにより、usernameを使用してAdminGetUserでユーザーを取得できます。
データベースでIDとしてusernameが本当に必要な場合は、ユーザーのアカウントが削除されたときにデータベースからユーザーを削除するか、「事前サインアップ」トリガーを使用して、ユーザーがusernameはすでにデータベースにあります。
識別のためにsubを独自のデータベースに保存すると、Cognitoの現在の制限（からこの日付）の1つにユーザーがリストされますawsはサブ属性またはカスタム属性によるフィルターを許可していないため、ユーザー、後でこの保存されたユーザーの情報をコグニトから復元しようとすることはできません。なので、uuidを保存するにはusernameを使用し、prefered_username実際のユーザー名のエイリアスとして。
Javascript AWS.CognitoIdentityServiceProvider.ListUser では、他のユーザーでも同じです。
1つだけを保存したい場合、サブはおそらくあなたが提供した理由のために行く方法です。
それはユースケースに大きく依存しますが、このデータベースを使用して例のようなAPIを呼び出す必要がある場合、両方を追跡することと、2つの間のマッピングを追跡することは完全に有効なソリューションです。