- Neueste
- Die meisten Stimmen
- Die meisten Kommentare
Solution 1: Use authorization code sign-in and store the access token in such a way that the user can't access it. The hosted UI offers no native capacity for updating user attributes, so you have to code for attribute updates for the user to have access. This isn't foolproof of course: with a client-side app there's no way you can 100% insulate the access token from the user.
Solution 2: Set up two app clients, one that can write the phone_number attribute and one that can't. Users are global to a user pool, so you can sign users up at #1 and sign them in at #2.
Solution 3: Set phone_number as an alias but not required. Capture the phone number to an immutable custom attribute on sign-up (you can write immutable custom attributes once on sign-up). Use a pre sign-up Lambda trigger to write the custom attribute value to the phone_number attribute.
I have been having this issue and I think the only way is technically with Developer Attributes, which are not writable by an app client, but only admin-.. calls (not via access token either). If you did want these attributes to be in claims in your token however you will need to write a pre token lambda trigger.
There is one downside to this approach in that if this attribute is mapped from an external identity provider a developer attribute won't work, as it will require an app client to write to it which app client's cannot do. If you aren't doing attribute mapping then this doesn't matter.
Relevanter Inhalt
- AWS OFFICIALAktualisiert vor 2 Jahren
- AWS OFFICIALAktualisiert vor einem Jahr
- AWS OFFICIALAktualisiert vor einem Jahr
I don't think this is really an answer in my opinion, at the end of the day this is creating a proxy with increase functionality between Cognito and your application. But if you could figure out the details of the user pool you could get the tokens through the hosted UI. Such an approach wouldn't be secure.