Проверить подпись токена JWT

В настоящее время я разрабатываю бэкэнд Swift с использованием Vapor. Мой клиент iOS использует новую функцию iOS 13 «Войти через Apple». Когда пользователь входит в систему, я получаю токен идентификации (токен доступа), который является действительным токеном JWT, подписанным Apple. Он отправляется на сервер во всех текущих сеансах связи для проверки подлинности некоторых маршрутов, предоставляемых сервером.

На сервере я хотел бы подтвердить, что отправленный токен действительно был подписан Apple и не был специально создан каким-либо злоумышленником путем проверки подписи токена. Apple предоставляет конечную точку HTTP для получения открытого ключа: Документация Apple.

Однако я не уверен в том, как часто мне приходится запрашивать эту конечную точку, чтобы получить модуль и показатель степени из API и построить открытый ключ для последующей проверки подписи. Достаточно ли запросить это один раз и сохранить открытый ключ на сервере, чтобы использовать это, или мне нужно будет запросить конечную точку HTTP в моем промежуточном программном обеспечении перед проверкой подписи (для каждого защищенного маршрута)?

В принципе, я не уверен, будут ли время от времени меняться модуль и экспонента.


person dehlen    schedule 19.06.2019    source источник
comment
jwt.io содержит список библиотек для проверки JWT для всех популярных языков.   -  person user28434'mstep    schedule 19.06.2019
comment
Почему должен измениться открытый ключ?   -  person    schedule 19.06.2019
comment
@ user28434 Я знаю, как проверить подпись, я не уверен, как часто может изменяться открытый ключ.   -  person dehlen    schedule 19.06.2019
comment
@LutzHorn Я не уверен. Поскольку ключи находятся вне моего контроля, я хотел действовать осторожно, поскольку при изменении ключа мой сервер больше не будет работать, поскольку все токены не могут быть проверены. Однако, если бы я мог просто один раз сгенерировать ключ и использовать его на своем сервере, это было бы фантастически, поскольку это означает отсутствие ненужных HTTP-запросов и сокращение накладных расходов для меня.   -  person dehlen    schedule 19.06.2019
comment
Если вы пользуетесь сервисом Apple, вы должны использовать их открытый ключ. Так что вы имеете в виду, говоря «сгенерировать ключ один раз»? Если вы не контролируете службу, выдающую JWT, вы не контролируете ключи.   -  person    schedule 19.06.2019
comment
С помощью «сгенерировать ключ один раз» я имел в виду сгенерировать открытый ключ на основе модуля и экспоненты, предоставляемых API (см. Ссылку в вопросе на документацию Apple выше).   -  person dehlen    schedule 19.06.2019


Ответы (1)


Вы могли сделать это:

  • получить открытый ключ один раз, сохранить его на своем сервере
  • поступает запрос, попробуйте проверить подпись, используя сохраненный открытый ключ
  • если это не удается, снова получите открытый ключ, сохраните его
  • попробуйте проверить подпись второй раз

Это позволит вам узнать об измененном открытом ключе, как только это будет необходимо.

person Community    schedule 19.06.2019
comment
Что ж, это, очевидно, отличный подход к проблеме. Большое спасибо :) - person dehlen; 19.06.2019
comment
Просто дополнительный момент, допустим, у десяти пользователей свои JWT1 подписаны ключом key1. Затем Apple меняет свой ключ на key2. А затем предположим, что десять других пользователей подписали свои JWT2 с помощью key2 (на данный момент в вашей системе все еще есть key1). Теперь предположим, что пользователь использует JWT2, тогда ваша проверка не удастся, вы получите открытый ключ от Apple и попытаетесь снова, что приведет к проверке. Теперь предположим, что десять пользователей отправили вам JWT1, это означает, что вы в конечном итоге будете получать данные из Apple 10 раз и каждый раз терпеть неудачу. Следовательно, вы можете захотеть хранить все различные ключи, которые вы получаете от Apple, в самой БД. - person Rishabh Poddar; 19.06.2019