Sign with apple facebook

Добавляем Sign in with Apple на back-end

На WWDC 2019 Apple представила новую систему авторизации пользователей — Sign in with Apple. Возникла задача интегрировать её в наш back-end и синхронизировать её с уже существующими методами авторизации при помощи email, Google и Facebook. За задачу взялся наш коллега kurenkoff, он и является автором данной статьи. Заинтересовавшихся просим под кат.

Процедура регистрации и авторизации пользователя через Apple

Процедура достаточно примитивная и происходит точно так, как указано на схеме от Apple.

Помимо этого, Apple предоставляет возможность обновления токена:

Схема тоже достаточно простая, есть возможность делать верификацию токена, но мы не используем эту возможность, т.к. у нас нет в этом необходимости.

Реализация авторизации через AppleID

Для реализации авторизации через AppleID мы используем пакет appleLogin. Автором данного пакета допущены некоторые ошибки, но они не являются критическими (а некоторые были совместно исправлены). В первую очередь необходимо инициализировать конфиг при помощи данных полученных через портал разработчика Apple.

Затем получить токен:

Важно заметить, какой запрос отправляется на сервера Apple. В документации сказано, что для авторизации необходимо отправить поля client_id, client_secret, code, grant_type, redirect_uri. Все эти поля описаны как обязательные, но redirect_uri можно опустить. Основную сложность представляет client_secret — это JWT, подписанный ключом сгенерированным на портале WWDR:

API Apple ответит либо ошибкой, либо вернет структуру. Нас интересуют поле IDToken:

IDToken является JWT токеном содержащим данные пользователя:

Стоит обратить внимание на то, что email можно получить только при первой авторизации. При попытках повторной авторизации можно получить только ID (уникальный идентификатор пользователя в Sign in with Apple). Для регистрации пользователя нам достаточно этих данных.

Источник

Внедряем Sign in with Apple в свое iOS приложение

На WWDC 2019 Apple в очередной раз нарушила покой iOS разработчиков — представила новую систему авторизации пользователей Sign in with Apple. Теперь все iOS приложения, которые используют сторонние системы авторизации (Facebook, Twitter, etc.), должны в обязательном порядке реализовать Sign in with Apple, иначе выгонят из AppStore. Мы решили не испытывать судьбу и побежали внедрять эту фичу. Как именно мы это сделали — узнаете под катом.

Пишем сервис авторизации через Apple

В своей работе мы используем архитектуру VIPER+SOA, поэтому авторизацию через Apple мы сделали как отдельный сервис. Сначала мы оборачиваем данные в enum, чтобы удобно расширять типы авторизации (фейсбук, вк, гугл и т.д.):

Результат наружу будем передавать с помощью Observable из RxSwift:

Нюансы, о которых нужно знать

1. У Sign in with Apple нету функции logout в классическом понимании этого слова. Библиотека не хранит никакие данные, в отличие от других библиотек входа, поэтому нет необходимости стирать данные, полученные при логине.
2. Sign in with Apple получает имя и фамилию пользователя только один раз при самом первом логине. У сервера нет доступа к этим данным. При последующих попытках входа вам будут приходить только authorizationCode из ASAuthorizationAppleIDCredential. Поэтому мы на клиентской стороне храним имя и фамилию пользователя до тех пор, пока регистрация на сервере не завершится успешно.
3. Sign in with Apple позволяет пользователю подменить свой e-mail. На подмененный e-mail можно написать только с тех доменов, которые вы укажете в настройках на developer.apple.com
   
4. В этой статье описано то, как мы реализовали back-end часть.

Статья получилось небольшой, но надеемся что она была полезной для вас.

Источник

The fast, easy way to sign in to apps and websites.

Sign in with Apple makes it easy for users to sign in to your apps and websites using their Apple ID. Instead of filling out forms, verifying email addresses, and choosing new passwords, they can use Sign in with Apple to set up an account and start using your app right away. All accounts are protected with two-factor authentication for superior security, and Apple will not track users’ activity in your app or website.

Respect for privacy.

Sign in with Apple was built from the ground up to give users peace of mind about their privacy. Data collection is limited to the user’s name and email address, and Apple’s private email relay lets users receive email even if they prefer to keep their address private. Apple will not track users as they interact with your app.

Security built in.

Every account using Sign in with Apple is automatically protected with two-factor authentication. On Apple devices, users are persistently signed in and can re-authenticate anytime with Face ID or Touch ID.

Antifraud.

Sign in with Apple is designed to give you confidence in your new users. It uses on-device machine learning and other information to provide a new privacy-friendly signal that helps you determine if a new user is a real person or an account you might want to take another look at.

Works everywhere.

Sign in with Apple works natively on iOS, macOS, tvOS, and watchOS. And it works in any browser, which means you can deploy it on your website and in versions of your apps running on other platforms.

Get Started

Learn how to plan, implement, and test Sign in with Apple in your apps and websites.

Источник

Внедряем Sign in with Apple — систему авторизации от Apple

Этим летом на конференции WWDC 2019 Apple представила собственную систему авторизации Sign in with Apple и сделала ее обязательной для всех приложений в App Store, которые используют вход через соцсети. Исключение составляют образовательные, корпоративные, правительственные и бизнес-приложения, использующие собственную авторизацию. К Sign in with Apple Apple сделала качественную документацию, и в этой статье мы на примере ЦИАН расскажем, как внедрить ее в свой сервис.

Настраиваем Apple Developer Account

Работа по интеграции начинается с настройки аккаунта разработчика. Сначала нужно включить опцию Sign In with Apple для вашего App ID. Для этого заходим в список идентификаторов в Apple Developer Account, выбираем необходимый App ID и включаем для него опцию Sign In with Apple.

Теперь настраиваем Service ID — уникальный идентификатор web-приложения, который понадобится для обращения к Sign in with Apple API. Всего на один App ID можно создать до 5 Service ID. Для этого нажимаем кнопку создания идентификаторов, выбираем Service ID, заполняем необходимые поля и нажимаем Edit в поле Sign In With Apple. Откроется форма, где выбираем правильный Primary App ID, указываем веб-домен и перечислям URL для редиректа после успешного логина. Надо учитывать, что можно ввести только 10 Return URLs:

Для сохранения нажимаем Save, Continue и Register. Да, при любых изменениях конфигурации необходимо нажимать все три кнопки, иначе изменения не вступят в силу.

Теперь в списке Service ID выбираем созданный идентификатор и опять нажимаем Edit в поле Sign In With Apple. В открывшемся окне у поля с веб-адресом видим две новые кнопки:

Этот файл необходим, чтобы Apple верифицировала ваш ресурс. Скачиваем его и размещаем его на своем ресурсе. Сразу у нас этот финт не сработал: когда наши админы добавили файл, то по указанному url срабатывал редирект (302) на файл, лежащий в другом месте, и Apple его не верифицировал. Тогда пришлось размещать файл по прямому доступу по URL (200). После того как Apple успешно проверит файл, рядом с доменом загорится зеленая галочка:

Из раздела идентификаторов переходим в раздел Keys и создаем новый ключ. Для этого ставим галочку Sign In with Apple и нажимаем сначала Configure, чтобы проверить App ID, затем Continue:

На следующем экране обязательно скачиваем файл с ключом и сохраняем его в безопасном месте, так как после ухода с этого экрана ключ будет недоступен для скачивания. На этой же странице можно увидеть Key ID, который нам еще понадобится:

Для пользователей у Sign In with Apple есть бонус: она позволяет предоставить фейковый e-mail, на который можно писать только с доверенных адресов. В этом случае нужна дополнительная настройка. Открываем раздел More, нажимаем Configure в разделе Sign In with Apple и вписываем свой URL:

Добавляем кнопку Sign In with Apple в iOS-приложение

ЦИАН работает на трех платформах: iOS, Android, Web. Для iOS есть нативное SDK, поэтому авторизация будет выглядеть следующим образом:

Чтобы добавить в iOS-приложение Sign in with Apple, добавляем кнопку ASAuthorizationAppleIDButton и вешаем на нее обработчик нажатия:

Кроме ASAuthorizationAppleIDProvider, обратите внимание еще на ASAuthorizationPasswordProvider, который позволяет получать связки «логин-пароль» из Keychain.

Теперь мы реализуем ASAuthorizationControllerPresentationContextProviding:

Создаем делегат ASAuthorizationControllerDelegate, который сообщает об успехе или ошибке:

Полученный authorizationCode мы отправляем на сервер и ждем ответа от бэкенда об успешности авторизации в нашей системе.

Реализуем Sign in with Apple для web и Android

Внезапно, для Android и Web Apple не предоставляет SDK, поэтому в обоих случаях нужно открыть страницу авторизации от Apple и процесс будет иным:

URL для страницы авторизации выглядит следующим образом:

Рассмотрим его параметры:

• client_id — Service ID, который регистрировали выше.
• redirect_uri — URI, куда пользователь перенаправляется после успешной аутентификации через AppleID. Этот URI мы указывали выше при настройке Apple Developer.
• state — идентификатор сессии пользователя, который Apple вернет при вызове redirect_uri, чтобы мы могли проверить отправителя. Правило генерации этого параметра можете придумать самостоятельно, например, рандомную строку.
• scope — в этом параметре указывается, какая нужна информация от пользователя. Например, name, email или сразу оба, как в примере выше.
• response_type — этот параметр указывает, в каком виде нужен ответ. Он может быть code или id_token. Если выбрать id_token, то его нужно уточнить параметром response_mode, в котором можно указать query, fragment и form_post.

После успешной двухфакторной аутентификации через appleID Apple вызовет указанный redirect_uri и передаст параметры state и code:

В параметре code передается одноразовый код аутентификации пользователя, который действует в течение 5 минут. В параметре state — идентификатор сессии, отправленный при создании формы авторизации, а в параметре user — данные пользователя.

Получение данных

На всех клиентах, чтобы сохранить данные пользователя, нужно получить от Apple access_token. Для этого сначала запрашиваем authorization_code:

• в client_id указывается созданный для web-приложений ServiceID и AppID для iOS-приложения.
• code — мы получили выше после редиректа или передали с iOS-клиента
• в параметре grant_type передаем цель получения токена: авторизация (authorization_code) или продление токена (refresh_token)
• в параметре client_secret — JSON Web Tokens на основе секретного ключа, полученного при регистрации приложения.

Создать JSON Web Tokens можно на Python:

Если все прошло успешно, то в ответе придут такие параметры:

Ура, вот и access_token. Вместе с ним приходит refresh_token, которым можно обновить при необходимости access_token.

Информация о пользователе хранится в поле id_token, но его нужно декодировать:

Apple_public_key — это публичный ключ, который можно получить по ссылке.

После декодирования получаем:

Email передается только один раз, когда пользователь впервые авторизуется в вашем сервисе через Sign in with Apple. В следующий раз Apple передаст эти данные только в том случае, если пользователь самостоятельно отвяжет ваше приложение. Этим авторизация от Apple отличается от других сервисов, где данные можно получить через API, и мы не нашли информацию о том, что они планируют реализовать что-то подобное.

В этом ответе нам нужны параметры sub, который передается каждый раз, и email, поэтому мы сохраняем их у себя в системе и сообщаем клиенту о успешной авторизации. PROFIT.

Источник

Запили Sign in with Apple, или 30 апреля (точнее июня) твоё приложение превратится в тыкву

Компания Apple опубликовала следующую новость 4 марта 2020 г.: “Все новые приложения и апдейты должны соответствовать новым гайдлайнам ревью и интерфейса к 30 апреля (перенесено на июнь) 2020.”

И главным новшеством этих гайдлайнов является обязательное наличие рабочей кнопки “Sign in with Apple” (SIWA) для приложений, позволяющих логиниться через сторонние сервисы (Facebook, Google, Twitter и т.д.).

Казалось бы, всё просто, но есть нюансы →

А можно не делать “Sign in with Apple”?

Да, если выполняется одно из следующих условий:

• Ваше приложение использует только вашу собственную систему аутентификации.
• У вас обучающее, корпоративное или бизнес приложение, которое требует аутентификации через существующий образовательный или корпоративный аккаунт.
• Ваше приложение использует государственную или отраслевую систему идентификации граждан или электронный идентификатор для аутентификации пользователей.
• Ваше приложение является клиентом для определенной сторонней службы, и пользователи должны войти в свою почту, социальные сети или другую стороннюю учетную запись напрямую, чтобы получить доступ к своему контенту.

Опыт компаний

На Хабре уже было несколько хороших статей про техническую сторону этого дела:

Некоторые пишут, что юзеры очень охотно жмакают новую кнопку, и даже связывают рост аудитории с реализацией SIWA.

Пикантные моменты

SIWA поддерживается с iOS 13 и iPadOS 13.1, так что есть повод попросить у компании новый мощный айфон для тестирования. Эппл — это особенная компания, и кнопка логина через эппл получилась у них особенной. При кажущейся простоте задачи, рекомендую обратить внимание на следующие вещи.

Пользовательские данные посылаются только один раз

Sign in with Apple получает имя, фамилию и имейл пользователя только один раз при первом логине. У сервера нет доступа к этим данным. При последующих попытках входа приходят только authorizationCode из ASAuthorizationAppleIDCredential.
Источник: Sports.ru

Поэтому на клиентской стороне нужно хранить данные пользователя до тех пор, пока регистрация на сервере не завершится успешно.

Ключик максимум на 6 месяцев

Максимальный срок, на который можно сгенерировать client_secret JWT токен равен 6 месяцам.
Совет — встройте процедуру перегенерации токена в свой пайплайн, а также делайте ключи на 1 месяц, чтобы обеспечить сесурити и исключить возможность протухания ключа на проде.
Можно также сделать хелс чек, который будет проверять валидность или срок действия ключа.

Функция Logout отсутствует

У SOWA нету функции logout в классическом понимании этого слова. Библиотека не хранит никакие данные, в отличие от других библиотек входа, поэтому нет необходимости стирать данные, полученные при логине.
Источник: Sports.ru

Юзер может скрыть свой имейл и выбрать себе имя

Пользователь может выбрать опцию Hide my email. В этом случае вы получите его прокси имейл, созданный эпплом вида random_chars@privaterelay.appleid.com. По умолчанию, на такие адреса нельзя ничего отправить, не сделав дополнительных телодвижений.

Вот гайд, описывающий принцип работы таких имейлов, а вот инструкции по настройке эппл аккаунта и сервисов рассылки, чтобы можно было отправлять письма на privaterelay ящики.

А еще в гайдлайнах есть фраза “Avoid asking for a personal email address when people supply a private relay address.” В конце материала есть вопрос к читателям на этот счет.

Юзер может указать себе любое имя и фамилию, причем фамилия может быть пустой — так что пересмотрите все места в вашем приложении, где используются эти данные.

И конечно же не забывайте добавить Apple ID, имя, фамилию и имейл в свои PII и GDPR процедуры, они же у вас есть.

Не совсем полная документация

Скорее всего придется попотеть с client_secret. В этой статье подробно расписано, как его генерировать.

Только трушный яблочный дизайн

Только попробуйте перевернуть яблоко или сделать отступы чуть больше — сразу в бан.

Из интересных моментов:

• Нельзя юзать просто лого как кнопку
• Высота лого должна соответствовать высоте кнопки
• Нельзя обрезать лого
• Нельзя добавлять вертикальный отступ
• Нельзя кастомизировать цвета лого
• Использовать только шрифт системы
• Размер шрифта должен составлять 43% от высоты кнопки

Для читателей в конце материала есть пример и вопрос на эту тему.

SIWA не только для яблочных девайсов

Можно добавить вход через эппл для веб платформ и даже Андроид приложений, используя JavaScript API.

Вопросы знатокам

1 — Дизайн кнопки

Пропустит ли аппстор проверка кнопку с таким дизайном?

Остальные кнопки в нашем приложении имеют именно такой стиль, поэтому плоская кнопка, выполненная по всем гайдлайнам смотрелась бы как инородный элемент.

2 — Какие данные показывать

У пользователя был аккаунт в приложении и имя с имейлом мы взяли с его фейсбук аккаунта (фейсбук явно это спрашивает и пользователь дает согласие). Теперь этот же пользователь привязал к своему аккаунту Apple Sign in, где указал другое имя и выбрал опцию “hide my email”.

Какие данные указывать в приложении — фейсбучные или эппловские?

3 — Как узнать, что все в порядке

Вот сделали мы SIWA — а как быть уверенными, что все по гайдлайнам, и что приложение пройдёт проверку в аппсторе после 30 июня (но узнать это уже сейчас)?

Может, на Хабре есть кто-то из официальных представителей…

P.S.

Надеюсь, что эта новость была для вас похожа на записку от Капитана Очевидность, и вы всё уже давно реализовали.

А если нет … расслабьтесь — у вас есть ещё 2 несколько спринтов!

Автор материала — Александр Зинчук, продакт менеджер. Новостной материал опубликован в блоге компании Alconost Inc. с разрешения автора.

Источник