Working with user attributes
Attributes are pieces of information that help you identify individual users, such as name, email address, and phone number. A new user pool has a set of default standard attributes. You can also add custom attributes to your user pool definition in the AWS Management Console. This topic describes those attributes in detail and gives you tips on how to set up your user pool.
Don't store all information about your users in attributes. For example, keep user data that changes frequently, such as usage statistics or game scores, in a separate data store, such as Amazon Cognito Sync or Amazon DynamoDB.
Note
Some documentation and standards refer to attributes as members.
Topics
Standard attributes
Amazon Cognito assigns all users a set of standard attributes based on the OpenID Connect
specification
The standard attributes are:
-
name
-
family_name
-
given_name
-
middle_name
-
nickname
-
preferred_username
-
profile
-
picture
-
website
-
gender
-
birthdate
-
zoneinfo
-
locale
-
updated_at
-
address
-
email
-
phone_number
-
sub
Except for sub
, standard attributes are optional by default for all users. To
make an attribute required, during the user pool creation process, select the
Required check box next to the attribute. Amazon Cognito assigns a unique user
identifier value to each user's sub
attribute. Only the
email and phone_number attributes can be
verified.
Standard attributes have predefined properties that you can view in the
SchemaAttributes
parameter of a DescribeUserPool API response. You can set custom values for these attribute
properties, like data type, mutability, and length constraints. To modify standard attribute
properties, set their custom values in the CreateUserPool Schema parameter. The schema is also where you set required
attributes. You can't modify the properties of standard attributes when you create user pools
in the Amazon Cognito console.
Note
When you mark a standard attribute as Required, a user can't register unless they provide a value for the attribute. To create users and not give values for required attributes, administrators can use the AdminCreateUser API. After you create a user pool, you can't switch an attribute between required and not required.
Standard attribute details and format restrictions
- birthdate
-
Value must be a valid 10 character date in the format YYYY-MM-DD.
-
Users and administrators can verify email address values.
An administrator with proper AWS account permissions can change the user's email address and also mark it as verified. Mark an email address as verified with the AdminUpdateUserAttributes API or the admin-update-user-attributes AWS Command Line Interface (AWS CLI) command. With this command, the administrator can change the
email_verified
attribute totrue
. You can also edit a user in the Users menu of the Amazon Cognito console to mark an email address as verified.Value must be a valid email address string following the standard email format with @ symbol and domain, up to 2048 characters in length.
- phone_number
-
A user must provide a phone number if SMS multi-factor authentication (MFA) is active. For more information, see Adding MFA to a user pool.
Users and administrators can verify phone number values.
An administrator with proper AWS account permissions can change the user's phone number and also mark it as verified. Mark a phone number as verified with the AdminUpdateUserAttributes API or the admin-update-user-attributes AWS CLI command. With this command, the administrator can change the
phone_number_verified
attribute totrue
. You can also edit a user in the Users menu of the Amazon Cognito console to mark a phone number as verified.Important
Phone numbers must follow these format rules: A phone number must start with a plus (
+
) sign, followed immediately by the country code. A phone number can only contain the+
sign and digits. Remove any other characters from a phone number, such as parentheses, spaces, or dashes (-
) before you submit the value to the service. For example, a phone number based in the United States must follow this format:+14325551212
. - preferred_username
-
You can select
preferred_username
as required or as an alias, but not both. If thepreferred_username
is an alias, you can make a request to the UpdateUserAttributes API operation and add the attribute value after you confirm the user. - sub
-
Index and search your users based on the
sub
attribute. Thesub
attribute is a unique user identifier within each user pool. Users can change attributes likephone_number
andemail
. Thesub
attribute has a fixed value. For more information about finding users, see Managing and searching for user accounts.
View required attributes
Use the following procedure to view required attributes for a given user pool.
Note
You can't change required attributes after you create a user pool.
To view required attributes
-
Go to Amazon Cognito
in the AWS Management Console. If the console prompts you, enter your AWS credentials. -
Choose User Pools.
-
Choose an existing user pool from the list.
-
Choose the Sign-up menu.
-
In the Required attributes section, view the required attributes of your user pool.
Username and preferred username
The username
value is a separate attribute and not the same as the
name
attribute. Each user has a username
attribute. Amazon Cognito
automatically generates a username for federated users. You must provide a
username
attribute to create a local user in the Amazon Cognito directory. After you
create a user, you can't change the value of the username
attribute.
Developers can use the preferred_username
attribute to give users usernames
that they can change. For more information, see Customizing sign-in attributes.
If your application doesn't require a username, you don't need to ask users to provide one. Your app can create a unique username for users in the background. This can be useful if you want users to register and sign in with an email address and password. For more information, see Customizing sign-in attributes.
The username
must be unique within a user pool. A username
can
be reused, but only after you delete it and it is no longer in use. For information about the
string constraints to the username
attributes, see the username property of a SignUp API request.
Customizing sign-in attributes
When you create a user pool, you can set up username attributes if you want your users to be able to sign up and sign in with an email address or phone number as their username. Alternatively, you can set up alias attributes to give your users the option: they can include multiple attributes when they sign up, and then sign in with a username, preferred username, email address, or phone number.
Important
After you create a user pool, you can't change this setting.
How to choose between alias attributes and username attributes
Your requirement | Alias attributes | Username attributes |
---|---|---|
Users have multiple sign-in attributes | Yes¹ | No² |
Users must verify email address or phone number before they can sign in with it | Yes | No |
Sign up users with duplicate email addresses or phone numbers and prevent
UsernameExistsException errors³ |
Yes | No |
Can assign the same email address or phone number attribute value to more than one user | Yes⁴ | No |
¹ Available sign-in attributes are username, email address, phone number, and preferred username.
² Can sign in with email address or phone number.
³ Your user pool doesn't generate UsernameExistsException
errors when
users register with potentially-duplicate email addresses or phone numbers, but no username.
This behavior is independent of Prevent username existence errors,
which applies to sign-in, but not sign-up, operations.
⁴ Only the last user who has verified the attribute can sign in with it.
You can activate aliases if you want to allow your users to choose to enter their username or other attribute values when they sign in. By default, users sign in with their username and password. The username is a fixed value that users can't change. If you mark an attribute as an alias, users can sign in with that attribute in place of the username. You can mark the email address, phone number, and preferred username attributes as aliases. For example, if you select email address and phone number as aliases for a user pool, users in that user pool can sign in with their username, email address, or phone number, along with their password.
To choose alias attributes, select User name and at least one additional sign-in option when you create your user pool.
Note
When you configure your user pool to be case insensitive, a user can use either lowercase or uppercase letters to sign up or sign in with their alias. For more information, see CreateUserPool in the Amazon Cognito user pools API Reference.
If you select email address as an alias, Amazon Cognito doesn't accept a username that matches a valid email address format. Similarly, if you select phone number as an alias, Amazon Cognito doesn't accept a username for that user pool that matches a valid phone number format.
Note
Alias values must be unique in a user pool. If you configure an alias for an email
address or phone number, the value that you provide can be in a verified state in only
one account. During sign-up, if your user provides an email address or phone number as
an alias value and another user has already used that alias value, registration
succeeds. However, when a user tries to confirm the account with this email (or phone
number) and enters the valid code, Amazon Cognito returns an AliasExistsException
error. The error indicates to the user that an account with this email address (or
phone number) already exists. At this point, the user can abandon their attempt to
create the new account and instead try to reset the password for the old account. If
the user continues to create the new account, your app must call the
ConfirmSignUp
API with the forceAliasCreation
option.
ConfirmSignUp
with forceAliasCreation
moves the alias from
the previous account to the newly created account, and marks the attribute unverified
in the previous account.
Phone numbers and email addresses only become active aliases for a user after your user verifies the phone numbers and email addresses. We recommend that you choose automatic verification of email addresses and phone numbers if you use them as aliases.
Choose alias attributes to prevent UsernameExistsException
errors for
email address and phone number attributes when your users sign up.
Activate the preferred_username
attribute so that your user can change
the username that they use to sign in while their username
attribute value
doesn't change. If you want to set up this user experience, submit the new
username
value as a preferred_username
and choose
preferred_username
as an alias. Then users can sign in with the new value
that they entered. If you select preferred_username
as an alias, your user
can provide the value only when they confirm an account. They can't provide the value
during registration.
When the user signs up with a username, you can choose if they can sign in with one or more of the following aliases.
-
Verified email address
-
Verified phone number
-
Preferred username
After the user signs up, they can change these aliases.
Important
When your user pool supports sign-in with aliases and you want to authorize or
look up a user, don't identify your user by any of their sign-in attributes. The
fixed-value user identifier sub
is the only consistent indicator of your
user's identity.
Include the following steps when you create the user pool so that users can sign in with an alias.
To configure a user pool so that users can sign in with a preferred username
-
Go to Amazon Cognito
in the AWS Management Console. If the console prompts you, enter your AWS credentials. -
Choose User Pools.
-
In the top-right corner of the page, choose Create a user pool to start the user pool creation wizard.
-
In Configure sign-in experience, choose the identity Provider types that you want to associate with your user pool.
-
Under Cognito user pool sign-in options, choose any combination of User name, Email, and Phone number.
-
Under User name requirements, choose Allow users to sign in with a preferred user name so that your users can set an alternate username when they sign in.
-
Choose Next, and then complete all of the steps in the wizard.
When the user signs up with an email address or phone number as their username, you can choose if they can sign up with only email addresses, only phone numbers, or either one.
To choose username attributes, don't select User name as a sign-in option when you create your user pool.
The email address or phone number must be unique, and it must not already be in use by another user. It doesn't have to be verified. After the user has signed up with an email address or phone number, the user can't create a new account with the same email address or phone number. The user can only reuse the existing account and reset the account password, if needed. However, the user can change the email address or phone number to a new email address or phone number. If the email address or phone number isn't already in use, it becomes the new username.
Note
If a user signs up with an email address as their username, they can change the username to another email address, but they can't change it to a phone number. If they sign up with a phone number, they can change the username to another phone number, but they can't change it to an email address.
Use the following steps during the user pool creation process to set up sign-up and sign-in with email address or phone number.
To configure a user pool for sign-up and sign-in with email address or phone number
-
Go to Amazon Cognito
in the AWS Management Console. If the console prompts you, enter your AWS credentials. -
Choose User Pools.
-
In the top-right corner of the page, choose Create a user pool to start the user pool creation wizard.
-
Under Cognito user pool sign-in options, choose any combination of Email and Phone number that represents the attributes that the user can use to sign in.
-
Choose Next, and then complete the remaining steps in the wizard.
Note
You do not need to mark email address or phone number as required attributes for your user pool.
To implement option 2 in your app
-
Call the
CreateUserPool
API to create your user pool. Set theUserNameAttributes
parameter tophone_number
,email
, orphone_number | email
. -
Call the
SignUp
API and pass an email address or phone number in theusername
parameter of the API. This API does the following:-
If the
username
string is in valid email address format, the user pool automatically populates theemail
attribute of the user with theusername
value. -
If the
username
string is in valid phone number format, the user pool automatically populates thephone_number
attribute of the user with theusername
value. -
If the
username
string format isn't in email address or phone number format, theSignUp
API returns an exception. -
The
SignUp
API generates a persistent UUID for your user, and uses it internally as the immutable username attribute. This UUID has the same value as thesub
claim in the user identity token. -
If the
username
string contains an email address or phone number that is already in use, theSignUp
API returns an exception.
-
You can use an email address or phone number as an alias in place of the username in
all APIs except the ListUsers
API. When you call ListUsers
,
you can search by the email
or phone_number
attribute. If you
search by username
, you must supply the actual username, not an
alias.
Custom attributes
You can add up to 50 custom attributes to your user pool. You can specify a minimum and/or maximum length for custom attributes. However, the maximum length for any custom attribute can be no more than 2048 characters.
Each custom attribute has the following characteristics:
-
You can define it as a string or a number. Amazon Cognito writes custom attribute values to the ID token only as strings.
-
You can't require that users provide a value for the attribute.
-
You can't remove or change it after you add it to the user pool.
-
The character length of the attribute name is within the limit that Amazon Cognito accepts. For more information, see Quotas in Amazon Cognito.
-
It can be mutable or immutable. You can only write a value to an immutable attribute when you create a user. You can change the value of a mutable attribute if your app client has write permission to the attribute. See Attribute permissions and scopes for more information.
Note
In your code, and in rules settings for Using role-based access control, custom attributes require the custom:
prefix to distinguish them from standard attributes.
You can also add developer attributes when you create
user pools, in the SchemaAttributes
property of CreateUserPool. Developer attributes have a dev:
prefix. You can only
modify a user's developer attributes with AWS credentials. Developer attributes are a legacy
feature that Amazon Cognito replaced with app client read-write permissions.
Use the following procedure to create a new custom attribute.
To add a custom attribute using the console
-
Go to Amazon Cognito
in the AWS Management Console. If the console prompts you, enter your AWS credentials. -
Choose User Pools.
-
Choose an existing user pool from the list.
-
Choose the Sign-up menu, and in the Custom attributes section, choose Add custom attributes.
-
On the Add custom attributes page, provide the following details about the new attribute:
-
Enter a Name.
-
Select a Type of either String or Number.
-
Enter a Min string length or number value.
-
Enter a Max string length or number value.
-
Select Mutable if you want to give users permission to change the value of a custom attribute after they set the initial value.
-
-
Choose Save changes.
Attribute permissions and scopes
For each app client, you can set read and write permissions for each user attribute. This way, you can control the access that any app has to read and modify each attribute that you store for your users. For example, you might have a custom attribute that indicates whether a user is a paying customer or not. Your apps might be able to see this attribute but not change it directly. Instead, you would update this attribute using an administrative tool or a background process. You can set permissions for user attributes from the Amazon Cognito console, the Amazon Cognito API, or the AWS CLI. By default, any new custom attributes aren't available until you set read and write permissions for them. By default, when you create a new app client, you grant your app read and write permissions for all standard and custom attributes. To limit your app to only the amount of information that it requires, assign specific permissions to attributes in your app client configuration.
As a best practice, specify attribute read and write permissions when you create an app client. Grant your app client access to the minimum set of user attributes that you need for the operation of your application.
Note
DescribeUserPoolClient only returns values for ReadAttributes
and
WriteAttributes
when you configure app client permissions other than the
default.
To update attribute permissions (AWS Management Console)
-
Go to Amazon Cognito
in the AWS Management Console. If the console prompts you, enter your AWS credentials. -
Choose User Pools.
-
Choose an existing user pool from the list.
-
Choose the App clients menu and choose an app client from the list.
-
In the Attribute permissions tab, choose Edit.
-
On the Edit attribute read and write permissions page, configure your read and write permissions, and then choose Save changes.
Repeat these steps for each app client that uses the custom attribute.
For each app client, you can mark attributes as readable or writeable. This applies to
both standard and custom attributes. Your app can retrieve the value of attributes that you
mark as readable, and can set or modify the value of attributes that you mark as writeable. If
your app tries to set a value for an attribute that it isn't authorized to write, Amazon Cognito
returns NotAuthorizedException
. GetUser requests include an access token with an app client claim; Amazon Cognito only
returns values for attributes that your app client can read. Your user's ID token from an app
only contains claims that correspond to the readable attributes. All app clients can write
user pool required attributes. You can only set the value of an attribute in an Amazon Cognito user pools API
request when you also provide a value for any required attributes that don't yet have a
value.
Custom attributes have distinct features for read and write permissions. You can create them as mutable or immutable for the user pool, and you can set them as read or write attributes for any app client.
An immutable custom attribute can be updated once, during user creation. You can populate an immutable attribute with the following methods.
-
SignUp
: A user signs up with an app client that has write access to an immutable custom attribute. They provide a value for that attribute. -
Sign-in with a third-party IdP: A user signs in to an app client that has write access to an immutable custom attribute. Your user pool configuration for their IdP has a rule to map a provided claim to an immutable attribute. This is possible but not practical, because the user will only be able to sign in one time. On sign-in attempts after their first, Amazon Cognito rejects the attempt because of the mapping rule to a now-unwriteable attribute.
-
AdminCreateUser
: You provide a value for an immutable attribute.
Attribute permissions with scopes
In user pools that you configure with an AWS SDK or CDK, the REST API, or the AWS CLI,
you can configure app client read or write access with the OIDC scope
oidc:profile
. The oidc:profile
grants read or write access to
the following standard attributes:
-
name
-
family_name
-
given_name
-
middle_name
-
nickname
-
preferred_username
-
profile
-
picture
-
website
-
gender
-
birthdate
-
zoneinfo
-
locale
This list is the OIDC standard attributes minus email
,
phone_number
, sub
, and address
, as defined in
section 2.4 of
the OIDC specification
To configure your app client to write to the attributes under the
oidc:profile
scope, set the value of WriteAttributes to oidc:profile
, plus any other attributes that you
want to permit your application to modify, in a CreateUserPoolClient or UpdateUserPoolClient API request. Similarly, to grant read access to these
attributes, add oidc:profile
to the value of ReadAttributes.
You can change attribute permissions and scopes after you have created your user pool.