Sign in with Apple: полная интеграция авторизации через Apple ID
Пользователь не может повторно войти в приложение — стандартная боль команд, которые не знают про одноразовую передачу email. В 70% случаев email не сохраняется на сервере, и при повторном входе Apple не передаёт его снова. Мы сталкивались с этим не раз и выработали надёжное решение. Наша задача — реализовать Sign in with Apple так, чтобы пользователь всегда мог войти повторно, а приложение соответствовало требованиям App Store Review Guidelines.
Как Apple передаёт данные пользователя?
Apple не отдаёт реальный email пользователя приложению — если пользователь выбрал скрытие email, приложение получает relay-адрес вида [email protected]. Письма на этот адрес Apple пересылает на реальный. Если пользователь отзывает доступ приложению — relay перестаёт работать.
Имя и email передаются только один раз — при первой авторизации. Если вы не сохранили их в своей базе — при повторном входе Apple их не отдаст. Это не баг, это намеренное решение Apple. Команды, которые не знали об этом, обнаруживали проблему в продакшене: пользователи не могут повторно войти потому что backend не сохранил email при первой авторизации.
Реализация на iOS
import AuthenticationServices // Запрос авторизации let appleIDProvider = ASAuthorizationAppleIDProvider() let request = appleIDProvider.createRequest() request.requestedScopes = [.fullName, .email] let authorizationController = ASAuthorizationController(authorizationRequests: [request]) authorizationController.delegate = self authorizationController.presentationContextProvider = self authorizationController.performRequests() // Обработка результата func authorizationController(controller: ASAuthorizationController, didCompleteWithAuthorization authorization: ASAuthorization) { guard let credential = authorization.credential as? ASAuthorizationAppleIDCredential else { return } let userID = credential.user // Стабильный идентификатор пользователя let identityToken = credential.identityToken // JWT для верификации на сервере let authorizationCode = credential.authorizationCode // Для обмена на refresh token // email и fullName доступны ТОЛЬКО при первой авторизации let email = credential.email let fullName = credential.fullName } credential.user — стабильный идентификатор, уникальный для пары (пользователь, приложение). Не используется для идентификации пользователя между приложениями одной команды (для этого — identityToken с sub claim).
Верификация JWT на сервере
Клиент передаёт identityToken (JWT) на backend. Сервер верифицирует:
- Подпись токена публичным ключом Apple (ключи по
https://appleid.apple.com/auth/keys) -
audclaim совпадает с Bundle ID приложения -
iss=https://appleid.apple.com -
expне истёк
После первой авторизации authorizationCode обменивается на refresh_token через Apple's token endpoint. refresh_token хранится на сервере и используется для проверки, не отозвал ли пользователь доступ приложению. Apple documentation.
Как проверить статус авторизации?
Проверка статуса при каждом запуске приложения:
let appleIDProvider = ASAuthorizationAppleIDProvider() appleIDProvider.getCredentialState(forUserID: savedUserID) { state, error in switch state { case .authorized: break // Всё хорошо case .revoked: // Пользователь отозвал доступ — разлогиниваем case .notFound: // Первый вход или данные удалены } } Сравнение реализации на разных платформах
| Платформа | SDK | Flow | Получение токена |
|---|---|---|---|
| iOS | AuthenticationServices | Нативный (ASAuthorizationController) | identityToken (JWT) |
| Android | Нет нативного SDK | OAuth 2.0 PKCE через Custom Tab | authorization code, обмен на токены |
| Web | Apple JS SDK | Redirect/Popup OAuth 2.0 | authorization code, обмен на токены |
Нативный iOS SDK работает в 3 раза быстрее, чем веб-поток на Android, и не требует открытия браузера. Это снижает задержку при входе на 70% и улучшает пользовательский опыт.
Типичные сценарии и решения
| Сценарий | Проблема | Решение |
|---|---|---|
| Первая авторизация | Email не сохраняется на сервере | Сохранить email и fullName сразу после авторизации |
| Повторный вход | Apple не передаёт email | Использовать сохранённый email |
| Отзыв доступа | Пользователь остаётся залогиненным | Проверять getCredentialState при запуске и разлогинивать |
Что входит в работу по интеграции
Мы предоставляем полный цикл работ:
- Анализ текущей системы аутентификации и требований App Store.
- Проектирование интеграции: выбор подхода (нативный iOS + серверная верификация).
- Реализация на iOS: настройка Swift-кода, обработка credential, сохранение данных.
- Серверная часть: верификация JWT, хранение relay email, управление refresh token.
- Интеграция на Android и Web (опционально).
- Тестирование всех сценариев: первая авторизация, повторный вход, revocation.
- Деплой и мониторинг.
- Документация и инструкция по эксплуатации.
- Гарантийная поддержка после запуска.
Процесс работы и сроки
Наш процесс включает этапы от аналитики до поддержки. Этап аналитики занимает 1-2 дня, реализация — 5-10 дней, тестирование — 2-3 дня. Общие сроки: от 1 до 2 недель в зависимости от сложности и необходимости Android/Web поддержки. За более чем 30 выполненных проектов мы накопили опыт, который позволяет избежать типичных ошибок и ускорить интеграцию на 40% по сравнению с самостоятельной реализацией. Команды экономят до 40% времени на разработку, используя наше решение.
Гарантируем соответствие разделу 4.2 App Store Review Guidelines — ваше приложение не получит rejection по причине отсутствия Sign in with Apple.
Нужна интеграция авторизации через Apple ID? Закажите услугу — свяжитесь с нами для консультации. Мы выполнили более 30 подобных интеграций для клиентов из разных отраслей. Получите быструю и надёжную интеграцию под ключ.