ну если уж начали про все эти федерированные логины - там концепция очень простая "доверяй и проверяй" - с одной стороны объявляем что наш сервис FOO  верит на слово провайдеру identity пользователей BAR (потому что админ настроил FOO так, выдал ему публичный ключ для проверки токенов от BAR), есть стандартные протоколы обмена - в каком формате запрашивается аутентификация от FOO и  присылаются данные от BAR (SAML 2.0, OIDC и все такое).
Дальше FOO,  когда пользователь логинится - определяет настройки его копии сервиса, и если там сказано что ходить только через AAD\Cognito - отправляет пользователя на настроенную копию  BAR-AAD\Cognito  (параметры при редиректе типа tenantId).
Там уже пользователь доказывает cognito что он "вася пупкин @ BAR" и знает пароль, имеет 2FA и все такое.  Когда он убедил BAR что он Вася, BAR-когнито генерит токен и отправляет его на FOO ( тем же редиректом),
FOO получает токен, который, в упрощенном виде говорит - "Впусти этого чела, как User123@Bar, его роли (claims) - Админ, "модератор группы" и "все Васи из BAR".
FOO проверяет что токен подписан приватным ключом BAR, не истек, предназначен именно для Foo а не для другого сервиса (пункт проверяй) и если все совпадает - FOO просто пускает пользователя принесшего токен и пишет там ему свою куку что вот пользователь user123@BAR соответствует моему пользователю F999@Foo и у него есть права админа и модератора и шильдик - все Васи из BAR
Собственно все, FOO никогда не видит почту или реальное имя пользователя, все что Foo знает это
1. Доверять всему что скажет BAR про пользователей в Foo
2. Пользователи приносят свои идентификаторы user123@BAR, а мы им выдаем права в нашей системе.

Сильно упрощено, но смысл передает. Так что когда у сервиса Foo есть интеграции по протоколу SAML  - тебе ненадо парится где хранятся PII данные пользователя и соответствует ли FOO регуляциям, просто потому что FOO никогда не получает PII данные пользователя, а только то, что говорит BAR.

я не совсем прям про бункер, я больше вообще ) ну т.е. я получил мыло от третьей стороны. по факту там может быть ваще даже не мыло а черти чо. как у login with apple, например. Т.е. чувак заходит через сторонний сервис, а не предоставляет мне идентификатор напрямую. идентификатор мне предоставляет сервис. это попадает под все эти адовые gdpr?

бункер хорошая идея, только меня смущает как это все бекапить и что делать, если вдруг база встанет раком )

ну если уж начали про все эти федерированные логины - там концепция очень простая "доверяй и проверяй" - с одной стороны объявляем что наш сервис FOO  верит на слово провайдеру identity пользователей BAR (потому что админ настроил FOO так, выдал ему публичный ключ для проверки токенов от BAR), есть стандартные протоколы обмена - в каком формате запрашивается аутентификация от FOO и  присылаются данные от BAR (SAML 2.0, OIDC и все такое).
Дальше FOO,  когда пользователь логинится - определяет настройки его копии сервиса, и если там сказано что ходить только через AAD\Cognito - отправляет пользователя на настроенную копию  BAR-AAD\Cognito  (параметры при редиректе типа tenantId).
Там уже пользователь доказывает cognito что он "вася пупкин @ BAR" и знает пароль, имеет 2FA и все такое.  Когда он убедил BAR что он Вася, BAR-когнито генерит токен и отправляет его на FOO ( тем же редиректом),
FOO получает токен, который, в упрощенном виде говорит - "Впусти этого чела, как User123@Bar, его роли (claims) - Админ, "модератор группы" и "все Васи из BAR".
FOO проверяет что токен подписан приватным ключом BAR, не истек, предназначен именно для Foo а не для другого сервиса (пункт проверяй) и если все совпадает - FOO просто пускает пользователя принесшего токен и пишет там ему свою куку что вот пользователь user123@BAR соответствует моему пользователю F999@Foo и у него есть права админа и модератора и шильдик - все Васи из BAR
Собственно все, FOO никогда не видит почту или реальное имя пользователя, все что Foo знает это
1. Доверять всему что скажет BAR про пользователей в Foo
2. Пользователи приносят свои идентификаторы user123@BAR, а мы им выдаем права в нашей системе.

Сильно упрощено, но смысл передает. Так что когда у сервиса Foo есть интеграции по протоколу SAML  - тебе ненадо парится где хранятся PII данные пользователя и соответствует ли FOO регуляциям, просто потому что FOO никогда не получает PII данные пользователя, а только то, что говорит BAR.

Сам не пробовал, но, говорят, толковый саас https://incountry.com

Интересный продукт. Очень похож на Databunker.

это если ты его извлекаешь и  хранишь. вообще при настройке интеграций можно указать что тебе ничего не нужно (и в OIDC и в SAML) так что если сервис разбазаривает емейлы своих пользователей когда ты их не запрашиваешь - это же не твоя зона ответственности. Понятно что в реальных системах чаще всего нужен email или какой-то другой способ поговорить напрямую с пользователем, но вообще для процедур 3rd partty auth эти данные не нужны, важно чтобы провайдер поддерживал уникальность и неизменность ID пользователя. UPD неправильно тут процитировал