Pull to refresh

Comments 15

А почему вы не использовали identityToken?
A JSON Web Token (JWT) used to communicate information about the identity of the user in a secure way to the app. The ID token will contain the following information: Issuer Identifier, Subject Identifier, Audience, Expiry Time and Issuance Time signed by Apple's identity service.

Мы используем idenityToken, но на back-end части. Со стороны iOS приложения никаких телодвижений делать не нужно.
Я правильно понимаю, что вы на back-end части получаете такой же idenityToken, который генерируется в приложении?
В приложение idenityToken не генерируется, в приложении генерируется code для авторизации. IdenityToken можно получить через API Apple.
Да, он есть, но мы не берем его из приложения, а back-end получает уже свой.
Соответственно, я возвращаюсь к своему изначальному вопросу. По какой причине вы не использовали identityToken, который генерируется в приложении? Почему вы приняли решение получать его именно на back-end? Это разные identityToken? Или быть может решили что это не безопасно его передавать от приложения к back-end?
Я так понимаю это рекомендация Apple.
В плане безопасности authorizationCode лучше — он одноразовый.
А по-поводу identityToken — он не такой удобный как кажется… В первый раз он содержит имя и мейл, во все последующие нет (даже если ты указываешь их в requestedScopes).
Пока я встречал два пути решения проблемы:
1) Хранить локально имя и мейл до завершения регистрации на сервере, как предлагает автор статьи.
2) Если регистрация была прервана, при следующей попытке просить пользователя удалить ассоциацию с приложением в Settings.
Вы не встречали в документации где Apple высказывалась мол не используйте identityToken, а используйте authorizationCode? Хотелось бы наверняка знать.

Можно при следующей попытке попросить пользователя ввести любые имя и мейл. Ведь главное получить id пользователя? И он отдается всегда. И он должен быть постоянным на всех девайсах данного пользователя в конкретном приложении.
Напрямую не встречал, но к примеру если сравнить описания:
A JSON Web Token (JWT) that securely communicates information about the user to your app.

и
A short-lived token used by your app for proof of authorization when interacting with the app’s server counterpart.

то мне кажется понятно как Apple предполагает их использовать.

Можно при следующей попытке попросить пользователя ввести любые имя и мейл.

О, спасибо! Это третий вариант. Ну он тоже не без недостатков, поскольку Apple возвращает «проверенный» мейл, а так пользователь может ввести все что угодно. Плюс пользователи не очень любят руками что-то вводить.

Согласен, пользователи не любят, но это скорее решение на крайний случай, который происходить будет редко. Если, например, у вас в приложении есть авторизация через VK и вы добавляете email в scope, то вы не всегда получите почту. Пользователь может запретить. В этом случае, как ни крути, надо показывать доп экран с просьбой ввести почту. И переиспользовать этот же экран для sign in with apple вполне себя оправдает.
Мой коллега kurenkoff немного ошибся. Мы действительно на клиенте можем получить identityToken. Решили использовать вместо него authorizationCode по соображениям безопасности, т.к. он имеет короткое время жизни.

При желании, можно делать как вы говорите — получать identityToken на клиенте и кидать его на сервер. Это вопрос конкретной реализации.
Я бы советовал добавить в Нюансы как раз реализацию logout. Если пользователь разорвал ассоциацию Apple ID с приложением в Settings (Settings/ Apple ID / Password & Security / Apple ID logins / Edit) вы должны выполнить logout в приложении / на сервере. Apple рекомендует проверять это на старте приложения с помощью ASAuthorizationAppleIDProvider().getCredentialState
Да, вы правы, однако мы имели в виду немного другое
Google и Facebook реализуют функцию logout() в своих библиотеках, а у Apple ее нет, так как в ней по сути нет необходимости
А проверкой токена на случай логаута от юзера у нас занимается back-end когда мы пытаемся получить данные пользователя
Only those users with full accounts are able to leave comments. Log in, please.