Я читал о связи между сервисами / микросервисами.
The API Gateway authenticates the request and passes an access token (e.g. JSON Web Token) that securely identifies the requestor in each request to the services. A service can include the access token in requests it makes to other services.
И я передаю токен доступа пользователя нижестоящим службам, поэтому это выглядит примерно так:
Но что, если срок действия токена истек между микросервисами?
Есть много способов решить эту проблему, и они кажутся разумными:
Проверить токен доступа пользователя и создать недолговечный JWT в API Gateway (вид внутренних токенов)
Each microservice validates the JWT and generates its own JWT to communicates with other microservices according to scope rules
Таким образом, у нас будет служба Auth для проверки или запроса токенов.
Квест:
Чтобы быть уверенным, что срок действия токена не истечет во время прохождения через службы, мы можем просто сделать проверку на уровне шлюза API: если токен истек через n (~ 1) минут, отклоните его, поэтому пользователь должен использовать токен обновления для получить новый токен доступа. Это означает, что токен всегда будет действителен в течение времени, необходимого для выполнения запроса. Какие плюсы и минусы такого подхода?





У меня такой же вопрос, поэтому Google привел меня сюда. Надеюсь, еще не поздно ответить на этот вопрос через полгода.
Не могу сказать, что это «ответ», но надеюсь, что моя идея может кого-нибудь чем-то вдохновить. Так что это своего рода «обмен идеями».
Думаю, есть два способа справиться с этой проблемой:
если срок действия токена истечет через 10 минут, обновите его через 6 минут (просто пример). Поэтому убедитесь, что ситуация, о которой вы сказали, никогда не произойдет, настроив время истечения срока действия и время обновления.
Другой способ - настроить архитектуру системы. Разделите API на внутренние и внешние. Все внешние токены будут проверяться на API Gateway, тогда токенов во внутренних сервисах нет.
Я думаю, что у нас есть много способов избежать проблемы, упомянутой в этом вопросе. Исходя из различных требований конкретного проекта, мы должны рассмотреть возможность использования другого дизайна безопасности. Так что никакой «серебряной пули» нет.