Немного подробнее, чем в комментариях.
Одним из источников вашей проблемы может быть сочетание небольшого времени жизни и несинхронизированных часов.
Был там и тоже прошел. Потребовалось время, чтобы понять это.
В вашем сценарии у вас есть 3 части с часами, которые манипулируют или проверяют маркер истечения срока действия.
Сервер идентификации, клиент и защищенный ресурс (PR).
Чтобы сделать объяснение немного более легким, давайте предположим, что все работает в UTC 0.
Ваш пользователь получает токен доступа от ID4 в полночь, устанавливает его в 00:00:00 и истекает через 20 секунд, срок действия токена истекает в 00: 00: 20.
Ваш клиент получает токен, хочет использовать его для запроса. Для этого он проверяет, не истек ли токен.
Часы клиента не синхронизированы с часами ID4, а на десять секунд вперед.
Так что на iOS это не точка полуночи, но уже 00:00:10. Поскольку срок действия токена истекает в 00:00:20, клиент говорит: позволяет использовать этот токен, он все еще действителен и отправляет его на защищенный ресурс.
Время на защищаемом ресурсе составляет 30 секунд. Таким образом, хотя это должно быть точка полуночи при получении запроса, это уже 00:00:30.
Проверка токена проверяет, является ли токен все еще действительным, видит, что он действителен до 00:00:20, и, следовательно, срок его действия истек. И защищенный ресурс возвращается неавторизованным.
Некоторые возможные шаги для решения этой проблемы.
Прежде всего, не используйте время жизни меньше 5 минут. Чем меньше срок службы, тем больше вес у часовых разниц.
Второй шаг, если это возможно, попытаться синхронизировать часы на сервере ID4 и защищенном ресурсе. Лучше всего работает, если они работают на одном сервере.
И, наконец, проверьте используемые вами библиотеки на клиенте и защищенном ресурсе для таких настроек, как перекос часов и когда клиент запрашивает новый токен доступа.
Если токен доступа имеет время ожидания один час, клиент может запросить новый за 5 минут до истечения срока действия токена.