Предполагая, что у вас есть существующая база данных / управление пользователями на веб-платформе. Вход в систему Apple должен быть интегрирован для более быстрого входа в систему и процесса регистрации - хотя всегда будет создаваться обычная учетная запись, привязанная к адресу электронной почты (только без обычного пароля). Безопасно ли использовать (проверенный) JWT, предоставленный Apple, для аутентификации?

Вход в систему (существующая учетная запись) будет состоять из следующих шагов:

  • Пользователь нажимает «Войти через Apple» в приложении.
  • сгенерированный JWT от Apple отправляется на сервер аутентификации
  • сервер проверяет JWT, используя открытые ключи, предоставленные конечной точкой Apple API
  • сервер извлекает электронное письмо из (проверенного) JWT, и если пользователь с этим адресом электронной почты существует, этот пользователь вошел в систему (API возвращает внутренний токен доступа / обновления для сеанса)
0
Dion 10 Фев 2021 в 18:24

1 ответ

Лучший ответ

Я пытаюсь найти ответ для приложений iOS. Но сначала проясните вопрос:

«Безопасно ли использовать (проверенный) JWT, предоставленный Apple, для аутентификации?»

Единственный известный JWT, который мы получаем от задачи авторизации, - это id_token. Другие параметры также могут быть JWT, но они непрозрачны для клиента.

Теперь возникает вопрос: если мы отправим id_token на сервер приложений, достаточно ли просто проверить id_token, чтобы передать клиенту токен доступа для домена сервера приложений? Ответ: НЕТ!

При использовании Apple Authentication Framework для iOS для входа в систему Apple задача авторизации возвращает значение ASAuthorization в обработчике завершения. Он содержит в основном следующие параметры:

  • user: идентификатор
  • identityToken: JWT "id_token" (см. OIDC)
  • authorizationCode: недолговечный, разовый действительный токен, который обеспечивает подтверждение авторизации для серверного компонента приложения. Код авторизации привязан к конкретной транзакции с помощью атрибута состояния, переданного в запросе авторизации. Серверный компонент приложения может проверять код с помощью конечной точки службы идентификации Apple, предоставленной для этой цели. *)

*) Если это значение действительно соответствует значению «кода» OIDC, которое будет получено клиентом через «передний канал» , также известный как пользовательский агент или браузер, то мы также должны убедиться, что дополнительный механизм на месте, которое фактически обеспечивает безопасное «подтверждение авторизации» (универсальные ссылки, PKCE), см. Атака с перехватом кода авторизации. Если эти атаки технически невозможны, поскольку система аутентификации обеспечивает безопасные каналы связи с приложением, нам не нужен PKCE.

Id_token содержит информацию о пользователе, который был аутентифицирован, который хранится в Провайдере. Это подписанный JWT. Даже если JWT может быть успешно проверен, только с JWT сервер приложения не может быть уверен, что отправитель является тем, кем он считает себя. Мы не хотим давать токен доступа никому без аутентификации!

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

Итак, мы должны выполнить два шага:

  1. Проверить токен удостоверения (id_token) Это будет выполняться на сервере приложений.

  2. Подтвердить код авторизации

На втором этапе сервер приложений получит токен обновления из специальных поставщиков конечные точки.

На шаге 2 мы получаем TokenResponse.

Если это было успешно, мы получаем токен доступа и токен обновления. Токен доступа бесполезен, но нам нужен токен обновления:

«Вы можете проверять токен обновления не чаще одного раза в день, чтобы подтвердить, что Apple ID пользователя на этом устройстве по-прежнему находится в хорошем состоянии на серверах Apple».

Сохраните это на своем сервере приложений.

После того, как все это будет сделано на вашем сервере приложений, вы продолжите:

Управление сеансом пользователя

После проверки токена удостоверения ваше приложение отвечает за управление сеансом пользователя. Вы можете связать время существования сеанса с успешными вызовами getCredentialState (forUserID: Завершение :) на устройствах Apple. Это недорогой локальный вызов вне сети, который включается системой Apple ID, которая поддерживает синхронизацию состояния Apple ID на устройстве с серверами Apple.

«Сеанс пользователя», скорее всего, потребует токен доступа для конкретного домена и токен обновления. Вы, вероятно, еще раз подтвердите токен обновления Apple, когда клиенту потребуется новый токен доступа на вашей конечной точке токена.

Итак, последний шаг - ваше приложение отправляет токен доступа для домена и токен обновления вашему клиенту.

1
CouchDeveloper 11 Фев 2021 в 21:36