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 подібних інтеграцій для клієнтів з різних галузей. Отримайте швидку та надійну інтеграцію під ключ.