ВНИМАНИЕ - при неправильном выполнении вы выставляете конфиденциальные атрибуты клиенту.
Вам необходимо создать 2 версии атрибутов - custom
и dev:custom
, сопоставить атрибуты провайдера c с custom
из них (похоже, dev:custom
не сопоставимы), затем в триггере TokenGeneration_HostedAuth
необходимо получить эти custom
атрибуты, установить dev:custom
единиц, а затем удалить custom
s.
Похоже на твик, но я не вижу другого способа сделать это и обеспечить безопасность токенов.
Решением для этого является создание пользовательских атрибутов в вашем пуле пользователей, а затем сопоставление этих атрибутов. для провайдера идентификации. Выглядит примерно так:
'custom:refresh_token': refresh_token
'custom:id_token': id_token
'custom:access_token': access_token
Шаблон облачной информации для этого:
пул пользователей
....
Schema: [
{
AttributeDataType: 'String',
DeveloperOnlyAttribute: true,
Mutable: true,
Name: 'refresh_token',
Required: false,
},
{
AttributeDataType: 'String',
DeveloperOnlyAttribute: true,
Mutable: true,
Name: 'access_token',
Required: false,
},
{
AttributeDataType: 'String',
DeveloperOnlyAttribute: true,
Mutable: true,
Name: 'id_token',
Required: false,
},
{
AttributeDataType: 'String',
Mutable: true,
Name: 'refresh_token',
Required: false,
},
{
AttributeDataType: 'String',
Mutable: true,
Name: 'access_token',
Required: false,
},
{
AttributeDataType: 'String',
Mutable: true,
Name: 'id_token',
Required: false,
},
],
....
провайдер идентификации пользователей пула
....
AttributeMapping: {
'custom:refresh_token': 'refresh_token',
'custom:access_token': 'access_token',
'custom:id_token': 'id_token',
},
....