#security #jwt #api-security
#Безопасность #jwt #api-безопасность
Вопрос:
Мой клиент — это компания, у которой есть учетные данные для моего веб-сервера, и я хочу, чтобы он разрешил своим конечным пользователям вызывать мой API с помощью JWT, который я предоставляю для него. это поток:
- Конечный пользователь запрашивает веб-страницу с веб-сервера клиента
- Если у конечного пользователя нет JWT для моего веб-сервера, сервер клиента вызывает мой API с его учетными данными, и я предоставляю ему новый JWT с истечением 1 часа
- Клиент отправляет JWT обратно своему конечному пользователю и сохраняет его в localstorage / cookies
- Конечный пользователь может вызвать мой API со своим JWT
- Когда конечный пользователь получает код состояния 401 из моего API с момента истечения срока его действия, он снова вызывает веб-сервер клиента на определенную конечную точку, чтобы получить новый JWT с истечением 1 часа для моего API, а затем он может снова вызвать мой API.
Я хочу знать ваше мнение об этом потоке и понять, разумно ли это. Есть ли способ улучшить этот поток? может быть, конечному пользователю следует искать свой токен и, если срок его действия истек, избегать вызова моего API и пропустить эту часть, чтобы сократить путь туда и обратно?
Ответ №1:
Концепция, которой следует следовать здесь, — это токен обновления.
В потоке OAuth вы можете использовать токен обновления, который можно использовать для получения нового токена, когда истекает срок действия существующего токена аутентификации.
Для получения более подробной информации о том, как его использовать, вы можете обратиться к статье OAuth здесь .
Комментарии:
1. Я знаю, что это концепция, и ключ API используется в качестве токена обновления в этом потоке, но я не хочу предоставлять конечному пользователю токен обновления, поскольку я хочу, чтобы только у клиента была возможность получить новый JWT.
2. @YairCohen извините, я думал, вы не знали о токене обновления, поскольку вы не упомянули, что хотите его избежать. Поскольку вы пытаетесь избежать этого, да — возможно, клиент может проверить время действия токена перед вызовом API и получить новый перед вызовом API.
3. @YairCohen Есть ли какая-либо конкретная причина, по которой вы не заинтересованы в совместном использовании токена обновления со временем истечения срока действия, скажем, 6 часов, чтобы ему нужно было получить доступ к веб-серверу для нового только по истечении срока действия обновления?
4. @ikamal извините, что не упомянул об этом. Я обновлю свой пост. Я не могу предоставить конечному пользователю токен обновления, поскольку я не могу сгенерировать для него новый JWT, поскольку Safari не поддерживает сторонние файлы cookie, и в будущем Chrome не будет поддерживать и это. Другая причина заключается в том, что я не хочу давать ему длительное время истечения срока действия без получения разрешения от моего клиента по соображениям безопасности.
5. @YairCohen да, я понял вашу озабоченность. Поэтому вам нужно будет попросить клиентов реализовать этот механизм на своей стороне; если они чувствуют, что процесс получения нового токена на основе 401 замедляет работу, они могут проверить время истечения срока действия JWT. Однако, учитывая, что клиенту в любом случае необходимо обработать 401, я считаю, что лучше оставить текущее решение таким, какое оно есть (только моя мысль :))