By using AWS re:Post, you agree to the AWS re:Post Terms of Use

Cognito: Is it possible to override the required social provider attribute mapping?

1

Hi! I'm working on a website using AWS Amplify and trying to implement social sign-in for Google. The issue is that we previously setup the required attributes to include birthday and gender which are incompatible with Google. We cannot re-create the userpool at this time as it's tightly linked to our product (e.g. using sub as UUID) and we already have around 100 users.

We have birthday and gender as our required attributes and get an error that looks like http://localhost:3000/?error_description=attributes+required%3A+%5Bgender%2C+birthdate%5D&state=CeuJOhpJRN0f2z4UljVnjOtehjuMwPRO&error=invalid_request

We want to prioritize social login over gender + birthday and are willing to drop that, however there doesn't seem to be a way to override the mapping to social providers. As a hack I tried to just map them to irrelevant fields (e.g. Gender -> Email), however that doesn't work for birthday as it needs to be the exact YYYY-MM-DD format.

Is there any way we can simply create fallback values based on if the attribute exists? This is also useful in the case of optional google attributes where some profiles include the scope. Another idea, is to allow users to explicitly not map their required Cognito attributes, although I understand the danger + inconsistency of that.

  • I am facing the exact same issue. We require given_name and family_name as attribute in our user pool. In testing, this fails when my family_name is not set.

    How can we provide a fall-back value or prompt the user to enter a value before the google auth token is used?

    We have a lot of users and do not want to migrate.

2 Answers
0

I understand your situation with implementing social sign-in for Google using AWS Cognito and the challenges you're facing with required attributes. Unfortunately, there isn't a straightforward way to override the required social provider attribute mapping in Cognito without modifying the user pool configuration.

However, there are a few potential workarounds you could consider:

  1. Modify attribute requirements: If possible, you could update your user pool to make birthday and gender optional instead of required. This would allow users to sign in with Google without providing these attributes.

  2. Custom attribute mapping: While you've already tried mapping to irrelevant fields, you could potentially create a more sophisticated mapping. For example, you could map a constant value or a default date for the birthday attribute that meets the YYYY-MM-DD format requirement.

  3. Pre-population of attributes: You could implement a post-authentication trigger (Lambda function) that runs after a user signs in with Google. This function could populate the required attributes with default values if they're missing.

  4. Two-step registration: Implement a flow where users first sign in with Google, and then prompt them to provide the missing required attributes before fully creating their account.

  5. Attribute mapping adjustment: Review your current attribute mapping configuration in Cognito. Ensure that you're only mapping the attributes that Google provides and that are compatible with your user pool requirements.

  6. Scopes adjustment: Make sure you're requesting the appropriate scopes from Google that align with your required attributes. However, keep in mind that some attributes like birthday might not be available or provided by Google.

It's important to note that these workarounds may have implications for data consistency and user experience. The ideal long-term solution would be to redesign your user pool to better accommodate social sign-in providers, but I understand that this isn't currently feasible given your existing user base and product integration.

If these options don't suit your needs, you might need to consider more complex solutions involving custom authentication flows or middleware to handle the attribute discrepancies between Google and your Cognito user pool.

Sources
Using social identity providers with a user pool - Amazon Cognito
Mapping IdP attributes to profiles and tokens - Amazon Cognito
Add social sign-in to your user pool - Amazon Cognito

profile picture
answered a month ago
0

Just updating this! I spoke with support and we found a technical solution where birthday can be mapped to Google's exp token which is a epoch token of length 10. Technically it will work for another 200+ years, so it's a good "temporary" solution.

There is currently no support to remove required attributes or fallbacks however.

answered 25 days ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions