Блог

Я пытаюсь создать RESTful API с использованием NodeJS, но у меня проблемы с пониманием правильного способа аутентификации пользователя с использованием токенов во время вызовов api. После прочтения некоторых блогов и статей я пришел к этим подходам:

Подход 1:

Токен доступа (AT) — это токен JWT, содержащий уникальный идентификатор пользователя в качестве полезной нагрузки JWT. Истекает через 1 день.
Токен обновления (RT) является случайным uuid с использованием пакета uuid npm. Хранится в базе данных вместе с пользовательским документом.
Процесс:

1. Когда сервер входа / регистрации пользователя выдает новый AT RT.
2. Если по истечении срока действия пользователь отправляет запрос на маршрут / refresh-token с помощью AT RT. Сервер проверяет правильность RT, сопоставляя RT, хранящийся в БД, с RT, заданным пользователем, и декодирует userId, присутствующий в AT, если AT является допустимым токеном JWT. Если все идет хорошо, RT является правильным и AT является действительным токеном JWT, сервер выдает новый AT и отправляет его пользователю.

В приведенном выше подходе токен обновления не истекает, поэтому, если RT попадает в руки вредоносного клиента, он может выдать n токенов доступа и совершать вызовы API, используя их, пока пользователь снова не войдет в систему, а сервер не сгенерирует новую пару AT RT. так что RT в руках злоумышленника бесполезен.

Подход 2:

На основе ротации токена запроса чтение при проверке подлинности документов при обновлении токена
Токен доступа (AT) — это токен JWT, содержащий уникальный идентификатор пользователя в качестве полезной нагрузки JWT. Истекает через 1 день.
Токен Referesh (RT) — это токен JWT. Истекает через 4-5 месяцев. Хранится в БД в виде массива токенов обновления отдельно от пользовательского документа.
Процесс:

1. Когда сервер входа / регистрации пользователя выдает новую пару AT RT и помещает RT в массив токенов обновления, хранящихся в БД.
2. Когда AT истекает, пользователь запрашивает / запрашивает маршрут токена со старой парой AT RT, и сервер генерирует новую пару AT RT, также сохраняет

Для вышеуказанного подхода, если токены попадают в руки вредоносного клиента, сервер может обнаружить его, используя следующий подход, описанный на рисунке ниже.

Реализация вышеуказанного подхода к обнаружению повторного использования токена в nodejs может быть следующей: если вредоносный клиент генерирует новую пару AT RT, а законный пользователь отправляет запросы на / запрос-маршрут токена (не подозревая о том, что вредоносный клиент сгенерировал новую пару AT RT, которая делает пользовательскую пару недействительной). Сервер наряду с проверкой того, действительны ли AT RT, может проверить, оба ли AT RT подписаны с помощью его секрета, и если RT, заданный пользователем, присутствует в массивах токена обновления, если он найден, это означает, что токен обновления используется повторно и может быть возможно, что токены просочились или украдены, что удаляет все этовыданные токены обновления запрашивают пользователя для повторного входа в систему.

мои вопросы таковы:
какой подход я должен использовать? и является ли это правильным способом реализации аутентификации?
ИЛИ мне следует использовать другой подход? (В этом случае, пожалуйста, предложите)

Я надеюсь, что опоздание на год не слишком поздно.

1. Для варианта 1 я предполагаю, что вы смотрите на что-то похожее на реализацию, описанную в этом сообщении. Возможно, стоит обратить внимание на то, что использование UUID в качестве refreshToken подвергает такой refreshToken вредоносным манипуляциям без обнаружения во время обходного перехода с сервера авторизации и на сервер авторизации, в то время как использование веб-токенов JSON предотвращает это
2. Из того, что я вижу, вариант 2 из документов Auth0 для токена обновления, как вы указали, хотя и не является пуленепробиваемым, но имеет естественное преимущество перед вариантом 1, поскольку не дожидается следующего входа, а следующего запроса другой стороны {legitimate_user, malicious_user}, чтобы заставить законного пользователя подписатьвыводит и делает токен обновления, которым владеет злоумышленник, неэффективным.
3. Дополнительное соображение и вопрос касаются деталей реализации и опций «Автоматического обнаружения повторного использования» из документов Auth0 для токена обновления, который является частью, дополняющей «Ротацию токена обновления«. В документе Auth0 упоминается «семейство» или «цепочка» refreshToken, каждый из которых происходит из начального refreshToken (я полагаю, что он связан с каждым входом в систему одного и того же пользователя, например, с разных устройств или разных типов браузеров). Итак, в базе данных у нас будет этот пользователь, связанный с несколькими семействами refreshToken, и когда мы обнаруживаем, что какой-то клиентский запрос пытается использовать refreshToken, который не является последним в семействе, чтобы попытаться получить новую пару accessToken / refreshToken, и в это время мы полностью удаляем это конкретное семейство. Я чувствую, что совершенно очевидно, что для того, чтобы это «автоматическое обнаружение повторного использования» работало, возможно, нам не нужно на самом деле сохранять «цепочку» для этого семейства в реализации этого, а просто последний сгенерированный refreshToken для этого семейства, но моя интуиция подсказывает мне, что я, возможно, что-то упустил.