Apple меняет домен Private Relay: почему Sign in with Apple нельзя строить вокруг email
24 августа 2026 года Apple объявила об изменении домена для новых адресов Private Relay, используемых в Sign in with Apple. В дальнейшем такие адреса будут создаваться в зоне `private.icloud.com`. Ранее выданные адреса `privaterelay.appleid.com` продолжат работать и пересылать сообщения без обязательной замены.
На первый взгляд это обычное обновление почтового суффикса. Разработчику достаточно проверить настройки отправки писем и при необходимости обновить список разрешенных доменов. Но на практике изменение показывает более серьезную архитектурную проблему: приложение не должно воспринимать email как постоянный идентификатор пользователя.
Что такое Private Relay и почему смена домена не требует миграции аккаунтов
Private Relay скрывает настоящий адрес пользователя. Вместо него приложение получает специальный email, а Apple пересылает письма на фактический почтовый ящик владельца учетной записи.
Для продукта такой адрес выглядит как обычный канал связи. На него можно отправлять уведомления, письма для восстановления доступа и сервисные сообщения. Однако он не подтверждает, что приложение знает настоящий email пользователя, и не должен использоваться как неизменный ключ аккаунта.
Новые адреса будут создаваться в домене `private.icloud.com`, тогда как ранее выпущенные адреса `privaterelay.appleid.com` сохранят работоспособность. Поэтому переписывать старые значения в базе, объединять записи или запускать массовую миграцию не нужно.
Есть и дополнительный нюанс: наличие адреса еще не гарантирует доставку. Пользователь может отключить пересылку, а отправляющая инфраструктура должна быть корректно зарегистрирована и настроена для работы с Private Relay. Состояние почтового канала следует хранить отдельно от данных об идентичности пользователя.
Email - это контакт, а не ключ учетной записи
Надежная модель авторизации разделяет как минимум три сущности:
- доказательство того, что вход выдан Apple;
- стабильную внешнюю идентичность пользователя;
- контактный адрес для отправки сообщений.
В Sign in with Apple постоянным идентификатором служит связка провайдера и `sub` - уникального идентификатора субъекта в подписанном токене. В базе это может выглядеть так:
```text
provider = apple
provider_subject = sub
```
Именно по этой паре нужно находить учетную запись при повторном входе. Email при этом остается атрибутом профиля или каналом коммуникации.
Подписанный identity token подтверждает происхождение запроса, но только после полноценной проверки. Необходимо убедиться в корректности подписи, значений `iss` и `aud`, сроке действия токена и соответствии `nonce`. Сам факт наличия email в payload ничего не гарантирует.
`sub` из проверенного токена связывает конкретную Apple identity с аккаунтом приложения. Его нельзя подменять адресом, потому что email способен измениться, исчезнуть или быть скрыт механизмом Private Relay.
Email выполняет другую функцию: помогает отправлять письма, отображается в профиле и может использоваться как дополнительный контакт. Из него нельзя автоматически делать доказательство владения аккаунтом или основание для объединения профилей.
Четыре опасных упрощения
1. Поиск Apple-пользователя только по email
Такая схема ломается сразу в нескольких случаях: пользователь скрывает адрес, Apple возвращает другой relay-адрес, email отсутствует в последующем ответе или адрес был изменен вручную.
Основной поиск должен выполняться по `provider + sub`. Email может использоваться только как вспомогательный атрибут, причем с понятными правилами подтверждения и обработки конфликтов.
2. Хранение в базе только email
Если в таблице нет внешнего идентификатора Apple, повторный вход превращается в угадывание. Система пытается определить владельца по адресу, который может быть неполным или изменившимся.
Минимальная модель должна содержать:
- внутренний ID пользователя;
- провайдера авторизации;
- идентификатор субъекта провайдера;
- текущий email;
- признак подтвержденности email;
- дату последнего обновления адреса.
Для пары `provider` и `provider_subject` нужен уникальный индекс.
3. Распознавание Private Relay только по домену
Проверять домен как технический признак допустимо для почтовой политики, но опасно использовать его в логике идентификации. Домен может измениться, а сам факт принадлежности адреса к relay не сообщает, кому именно принадлежит аккаунт.
Allowlist должен включать оба домена, если приложение действительно фильтрует адреса:
- `privaterelay.appleid.com`;
- `private.icloud.com`.
При этом проверка должна быть нечувствительной к регистру и не должна подменять проверку токена.
4. Автоматическое объединение аккаунтов по похожему email
Совпадение адресов - недостаточное основание для слияния профилей. Опасны не только точные совпадения, но и эвристики вроде игнорирования точек, плюсов, регистра или замены доменов.
Объединение допустимо только после явного подтверждения пользователя и дополнительной проверки владения обеими учетными записями. В противном случае система может случайно соединить чужие профили.
Что проверить за один рабочий день
Начать стоит с модели данных и индексов. Найдите таблицы пользователей, внешних identities, email-адресов и связей между ними. Проверьте, существует ли уникальное ограничение на `provider + sub`, а также допускает ли схема отсутствие email.
Затем изучите границу проверки токена. Убедитесь, что токен валидируется до записи любых claims в базу. Отдельно проверьте `nonce`, аудиторию приложения, издателя, срок действия и алгоритм подписи.
Следующий этап - поиск всех мест, где используется email. Это могут быть авторизация, восстановление доступа, дедупликация, уведомления, suppression-list, аналитика, поиск в панели поддержки и экспорт данных. Часто проблема скрывается не в основном login-flow, а в административных сценариях.
Наконец, проверьте логи. Не следует записывать туда полные токены и без необходимости раскрывать relay-адреса. Логи должны позволять расследовать ошибки, но не превращаться в дополнительное хранилище персональных данных.
Тесты, устойчивые к будущим изменениям Apple
Полезно добавить сценарии, в которых:
1. новый пользователь получает адрес `private.icloud.com`;
2. старый пользователь продолжает входить с `privaterelay.appleid.com`;
3. email отсутствует в повторном ответе;
4. имя приходит только при первом согласии;
5. пользователь отключил пересылку;
6. в базе уже существует такой email, но с другой Apple identity;
7. токен имеет неверный `aud`, `iss`, `nonce` или истекший срок действия;
8. один пользователь меняет контактный адрес;
9. один аккаунт подключает несколько способов входа;
10. relay-домен меняется без изменения `sub`.
Главный критерий успешного теста прост: смена email или домена не должна создавать новый аккаунт и не должна менять владельца уже существующей записи.
Если email уже используется как ключ
Миграцию лучше проводить поэтапно. Сначала добавьте таблицу внешних идентичностей или новые поля `provider` и `provider_subject`. Затем при следующем подтвержденном входе связывайте Apple identity с существующим профилем по безопасному сценарию.
Если связь по `sub` установить невозможно, не выполняйте автоматическое объединение по одному адресу. Покажите пользователю понятный процесс подтверждения: вход в прежний аккаунт, код на уже подтвержденный канал или ручную проверку в зависимости от уровня риска.
После накопления связей можно перевести авторизацию на новый ключ, оставив email для контактов и поиска. Старые записи следует проверять на дубли, конфликты и отсутствующие идентификаторы, но не изменять массово только из-за смены домена Private Relay.
Практическая архитектура
Удобно отделить профиль пользователя от способов входа:
```text
users
- id
- display_name
- contact_email
- email_status
identities
- user_id
- provider
- provider_subject
- created_at
- last_login_at
```
В такой схеме один пользователь может иметь Apple, Google, пароль и другие способы входа. Email не обязан быть уникальным глобально, если продукт не требует этого отдельно. Уникальность должна быть привязана к конкретному бизнес-правилу, а не принята автоматически.
Смена домена Private Relay в этом случае становится обычным изменением контактного атрибута. Идентичность пользователя остается прежней, потому что определяется не почтовым суффиксом, а подтвержденным идентификатором Apple.
Итог
Переход новых адресов Private Relay на `private.icloud.com` не требует массовой замены старых значений: адреса `privaterelay.appleid.com` продолжат работать. Но событие полезно использовать как повод проверить архитектуру авторизации.
Для Sign in with Apple email должен рассматриваться как контактный адрес, а не как ключ учетной записи. Надежная связка - это провайдер и `sub` из корректно проверенного токена. Такая модель защищает от дублей, ошибочных объединений и будущих изменений почтовой инфраструктуры Apple.