Реалізація входу через Apple ID на сайті

Уявіть: користувач iOS очікує ввійти на сайт через Apple ID, а у вас лише Google та email. Він іде до конкурента. Ми стикалися з цим не раз. Інтеграція Sign in with Apple — це не просто дотримання гайдлайнів, а спосіб утримати аудиторію Apple-пристроїв. За даними наших проєктів, конверсія входу через Apple ID серед iOS-користувачів на 25-30% вища, ніж через Google або email. Однак реалізація приховує багато підводних каменів: relay email не доходить, ім'я користувача втрачається при повторному вході, client_secret закінчується кожні 6 місяців. За нашими плечима 10+ років досвіду у веб-розробці та понад 50 успішних проєктів з авторизацією. Ми гарантуємо коректну роботу навіть з relay email та прихованими даними, економлячи до 20 годин на налагодження типових помилок.

Типові складнощі інтеграції Apple ID

Apple ID має ряд особливостей, які роблять його реалізацію нетривіальною:

• Користувач може приховати справжній email — Apple видає relay-адресу виду [email protected].
• id_token повертається лише при першій авторизації разом з іменем користувача.
• Наступні входи не повертають ім'я — його потрібно зберегти при першому вході.
• Немає refresh token у стандартному сенсі OAuth2.

Ці відмінності потребують особливого підходу: ми акуратно обробляємо кожен сценарій, щоб користувач не втратив доступ. Згідно з документацією Apple, relay-адреси можуть змінювати формат — ми враховуємо це в реалізації.

Як зареєструвати додаток в Apple Developer?

1. Certificates, Identifiers & Profiles → Identifiers → створити App ID з увімкненим Sign In with Apple.
2. Створити Services ID (web-компонент) — вказати домен та Redirect URL.
3. Створити Key з увімкненим Sign In with Apple — завантажити .p8 файл (зберігати безпечно, завантажити можна лише один раз).
4. Зафіксувати: Team ID, Client ID (= Services ID), Key ID.

Генерація client_secret

Apple не використовує статичний секрет. client_secret — JWT, підписаний приватним ключем .p8. Ми генеруємо його за допомогою бібліотеки lcobucci/jwt:

use Lcobucci\JWT\Configuration;
use Lcobucci\JWT\Signer\Ecdsa\Sha256;
use Lcobucci\JWT\Signer\Key\InMemory;

function generateAppleClientSecret(): string
{
    $config = Configuration::forAsymmetricSigner(
        new Sha256(),
        InMemory::file(storage_path('keys/apple_auth.p8')),
        InMemory::empty()
    );

    return $config->builder()
        ->issuedBy(config('services.apple.team_id'))         // iss: Team ID
        ->permittedFor('https://appleid.apple.com')          // aud
        ->relatedTo(config('services.apple.client_id'))      // sub: Services ID
        ->issuedAt(new \DateTimeImmutable())
        ->expiresAt(new \DateTimeImmutable('+6 months'))
        ->withHeader('kid', config('services.apple.key_id'))
        ->getToken($config->signer(), $config->signingKey())
        ->toString();
}

Термін дії до 6 місяців. Токен перестворюється заздалегідь через cron — ми автоматизуємо це, щоб інтеграція працювала без збоїв.

Чим відрізняється Apple OAuth від Google OAuth?

1. Редирект користувача:
   GET https://appleid.apple.com/auth/authorize
     ?client_id=com.example.web
     &redirect_uri=https://example.com/auth/apple/callback
     &response_type=code id_token
     &response_mode=form_post
     &scope=name email
     &state=<random_string>
     &nonce=<random_nonce>

2. Apple робить POST на redirect_uri з:
   - code
   - id_token
   - state
   - user (JSON з іменем — лише при першому вході!)

Як обробити callback та верифікувати id_token?

public function handleCallback(Request $request): RedirectResponse
{
    // Верифікація state
    abort_unless($request->state === session('apple_state'), 422);

    // Декодування id_token (без верифікації підпису поки)
    $idToken = $this->decodeIdToken($request->id_token);

    // user приходить тільки при першому вході
    $appleUser = $request->has('user')
        ? json_decode($request->user, true)
        : null;

    $user = User::updateOrCreate(
        ['apple_id' => $idToken['sub']],
        [
            'email'             => $idToken['email'] ?? null,
            'email_verified_at' => $idToken['email_verified'] ? now() : null,
            // Ім'я зберігаємо тільки якщо прийшло (перший вхід)
            'name' => $appleUser
                ? trim(($appleUser['name']['firstName'] ?? '') . ' ' . ($appleUser['name']['lastName'] ?? ''))
                : null,
        ]
    );

    // Оновлюємо ім'я тільки якщо воно не було встановлено раніше
    if ($appleUser && !$user->name) {
        $user->update(['name' => ...]);
    }

    Auth::login($user);

    return redirect()->intended('/dashboard');
}

Верифікація id_token

Apple публікує публічні ключі за адресою https://appleid.apple.com/auth/keys. Верифікація через JWT:

// composer require firebase/php-jwt
use Firebase\JWT\JWT;
use Firebase\JWT\JWK;

$keys = Cache::remember('apple_public_keys', 3600, function () {
    return Http::get('https://appleid.apple.com/auth/keys')->json();
});

$payload = JWT::decode($idToken, JWK::parseKeySet($keys));

// Перевірити: iss = appleid.apple.com, aud = client_id, exp, nonce

Як працювати з relay email?

Якщо користувач приховав email, Apple видає relay-адресу @privaterelay.appleid.com. Листи на неї доходять тільки якщо домен зареєстровано в Apple Developer Console → More → Configure Sign in with Apple for Email Communication. Ми допомагаємо налаштувати цей процес, щоб сповіщення доставлялися.

В одному з проєктів relay email не працював через відсутність реєстрації домену — помилка коштувала клієнту втрати частини замовлень. Ми швидко виявили причину та налаштували відповідність, відновивши доставку листів.

Що входить у роботу

• Реєстрація додатку в Apple Developer (App ID, Services ID, Key)
• Генерація client_secret JWT з автоматичним оновленням через cron
• Реалізація OAuth callback з верифікацією id_token та state
• Обробка relay email та прихованого імені (збереження при першому вході)
• Інтеграція з Laravel Socialite або кастомна реалізація
• Документація з підтримки та передача доступів
• Гарантія на код та безкоштовна консультація протягом місяця після здачі

Терміни робіт

Разом: 4–5 робочих днів.

Щоб отримати готову інтеграцію Apple ID під ключ, зв'яжіться з нами — ми оцінимо ваш проєкт і запропонуємо оптимальне рішення. Замовте інтеграцію вже сьогодні та позбавте себе годин налагодження типових помилок.

Аутентифікація та авторизація: OAuth, JWT, сесії, RBAC, 2FA

На одному проєкті токен JWT із роллю admin: false» міг бути змінений клієнтом на admin: true» — і сервер прийняв його без верифікації підпису. Ми знайшли це на тестовому стенді, коли робили огляд існуючої кодової бази новому замовнику. Причина — застаріла бібліотека jsonwebtoken, яка в певних версіях пропускала алгоритм «none». Наслідки — повний доступ до адміністративного API для будь-якого зареєстрованого користувача. Замовник не знав про це, але ми оцінили ризик, переписали модуль авторизації під ключ і запровадили обов’язкову перевірку алгоритму. Тепер подібних інцидентів немає. За 7+ років ми реалізували понад 50 проєктів із системами аутентифікації та авторизації користувачів — від стартапів до корпоративних рішень, що працюють із фінансовими даними.

Чому JWT не варто зберігати в localStorage?

JWT складається з трьох частин: header (алгоритм), payload (дані), signature (підпис). Підпис верифікує, що payload не змінено. Без перевірки підпису — це просто base64-encoded JSON, який будь-хто може підробити. Помилки, які бачимо в коді регулярно:

• Зберігання в localStorage. LocalStorage доступний будь-якому JS на сторінці — XSS-атака читає токен і відправляє на сервер зловмисника. Access token в пам’яті (змінна модуля), refresh token в httpOnly cookie — правильна схема.
• Довгоживучі access-токени. Access token на 7 днів без можливості відкликання — витік дає 7 днів доступу. Стандарт: 15 хвилин для access token, 30 днів для refresh token з ротацією. При кожному використанні refresh token видається новий, старий інвалідується — якщо старий хтось використовує повторно, це детектується як Token Reuse Attack, уся сім’я токенів відкликається.
• Зберігання секретних даних у payload. JWT payload не зашифровано, лише підписано — його видно в base64. Паролі, платіжні дані, особиста інформація — не в JWT. Алгоритм RS256 (асиметричний) кращий за HS256 (симетричний) у мікросервісній архітектурі: сервіси можуть верифікувати токен публічним ключем, не маючи доступу до секрету для його створення.

Як обрати між сесіями та токенами?

Сесії зберігають стан на сервері (Redis, database) — сервер може миттєво відкликати сесію. При масштабуванні на кілька інстансів потрібен спільний store (Redis Cluster). Cookie з session ID — httpOnly, Secure, SameSite=Strict.

Stateless JWT не вимагають server-side storage, масштабуються горизонтально. Але відкликання токена до завершення терміну — тільки через blacklist (Redis), що частково знімає перевагу stateless.

Для більшості веб-додатків сесії простіші та безпечніші. JWT має сенс для API, що споживаються з мобільного додатку, та для мікросервісної архітектури. Оцініть ваш сценарій — ми допоможемо обрати правильний підхід.

OAuth 2.0 та OpenID Connect

OAuth 2.0 — протокол делегованої авторизації, не аутентифікації. «Увійти через Google» — це OpenID Connect поверх OAuth 2.0, який додає id_token з даними користувача. Authorization Code Flow з PKCE — єдиний правильний flow для браузерних SPA та мобільних додатків. Implicit Flow застарів і небезпечний. PKCE (Proof Key for Code Exchange) захищає від перехоплення authorization code.

Реалізація OAuth сервера: не пишемо з нуля. Keycloak (open source, self-hosted), Auth0, Okta — готові рішення. Laravel Passport або Laravel Sanctum для серверних додатків. NextAuth.js для Next.js — підтримує 50+ провайдерів з коробки. Для B2B продуктів з корпоративними клієнтами — SAML 2.0 SSO. Корпоративні IT-відділи часто вимагають його замість OAuth. @boxyhq/saml-jackson — node.js бібліотека для SAML → OAuth2 адаптера.

RBAC, ABAC, ReBAC — що і коли застосовувати

Role-Based Access Control — у користувача є ролі, у ролей — права. Проста реалізація: user → roles → permissions. Але коли з'являється ресурсна авторизація («користувач може редагувати лише свої пости»), RBAC ускладнюється. У такому разі використовуйте Spatie Laravel Permission (стандарт для Laravel): поліморфні ролі та права, кешування, super-admin через gate. Інтеграція з Eloquent — $user->can('edit posts'), $user->hasRole('editor').

ABAC (Attribute-Based Access Control) — політики на основі атрибутів: користувача, ресурсу, середовища. Потрібен, коли правила доступу складні: «менеджер може переглядати замовлення свого регіону, якщо замовлення створено більше 24 годин тому». Casbin — популярна cross-language бібліотека для ABAC.

ReBAC (Relationship-Based Access Control) — Google Zanzibar model. Доступ визначається графом відносин: «користувач X є учасником команди Y, яка має доступ до проєкту Z». OpenFGA — open source реалізація від Okta.

Як ми це робимо: кейс із впровадження 2FA

Проєкт — платіжний шлюз для маркетплейсу. Потрібно було захистити доступ до операцій виводу коштів. Ми спроєктували систему:

• Основний пароль замінили на комбінацію пароль + TOTP (Google Authenticator). Використали otplib (Node.js) для генерації та верифікації кодів.
• Під час першого підключення 2FA показували QR-код (base32-encoded secret) і генерували 10 одноразових backup-кодів, хешованих bcrypt. Відображали коди лише один раз.
• Secret для TOTP зберігали у зашифрованому вигляді в базі даних (AES-256-GCM, ключ у AWS KMS).
• На стороні фронтенду інтегрували @simplewebauthn/browser для passkeys — біометрична аутентифікація як альтернатива паролю. Публічний ключ зберігали на сервері, private key на пристрої користувача.
• Результат: час на логін зріс на 5 секунд, але кількість зламаних акаунтів упала до нуля за пів року роботи. Гарантія безпеки — на рівні OWASP ASVS Level 2.

Також варто зазначити, що TOTP значно надійніше за SMS-верифікацію через SIM-swapping, тому для фінансових даних ми рекомендуємо TOTP або апаратні ключі.

Типові вразливості, які ми знаходимо

• Broken Object Level Authorization (BOLA/IDOR): /api/orders/12345 повертає замовлення без перевірки, чи належить воно поточному користувачу. Найпоширеніша вразливість API за OWASP. Кожен запит до ресурсу — перевірка через $user->can('view', $order).
• Mass Assignment: User::create($request->all()) — користувач передає is_admin: true в тілі запиту. Laravel вирішує через $fillable / $guarded, але часто забувають.
• Небезпечний CORS: Access-Control-Allow-Origin: * на API з авторизацією по cookie — credentials не передаються з wildcard origin, але якщо хтось зробив Allow-Credentials: true + Allow-Origin: * — це діра.

Penetration testing обов’язковий для продуктів з фінансовими даними або персональними даними користувачів. Ми проводимо аудит коду й інфраструктури на етапі приймання.

Що входить у роботу

Ми передаємо замовнику:

• Документацію архітектури авторизації (flow діаграми, опис токенів, політик доступу).
• Репозиторій із вихідним кодом, покритий unit- та integration-тестами.
• Конфігурацію для CI/CD (GitHub Actions/ GitLab CI) із перевірками безпеки.
• Доступи до середовищ (staging, production) із правами адміністратора.
• Інструкцію з експлуатації та супроводу.
• Підтримку після впровадження — 2 тижні безкоштовних консультацій.

Терміни та вартість

Базова аутентифікація (email/password + OAuth + JWT/сесії): 1–3 тижні. RBAC з детальними політиками доступу: 2–4 тижні. 2FA (TOTP + SMS): 1–2 тижні. WebAuthn/Passkeys: 2–3 тижні. Повна система аутентифікації для SaaS з multi-tenancy: 4–8 тижнів.

Вартість розраховується індивідуально залежно від обсягу та складності. Замовте консультацію — оцінимо ваш проєкт безкоштовно. Отримайте гарантію безпеки вашої авторизації користувачів.