The iss (issuer) claim identifies the principal that issued the JWT. The processing of this claim is generally application specific. The iss value is a case-sensitive string containing a StringOrURI value. Use of this claim is OPTIONAL.
Поставить срок жизни access token маленький например 30 мин, можно удалить в БД refresh token юзера, тогда нельзя будет получить новый access token и надо будет вводить логин пароль. Если токен не был украден то пользователь не заметит как приложение обновит access token через 30 мин, а если ктото другой использовал refresh token то они не совпадут и пользователю надо будет ввести логин пароль, в итоге украденый refresh token будет не валиден
— access_token не нужно хранить в базе данных, с помощью JWT можно хранить данные в токене — например userId, таким образом при каждом запросе к серверу мы избавляемся от лишнего запроса к базе данных так как ID юзера можно получить из токена
— refresh_token хеш который хранится в базе данных.
1. Сервер получает логин/пароль — создает access_token и refresh_token, сохраняет в базу refresh_token, отдает токены на клиент
2. Клиент использует access_token для доступа к данным пока приложение не будет закрыто, сохраняет refresh_token в хранилище
3. Если получает от сервера сообщение что срок access_token истек — отправляет запрос на авторизацию с refresh_token, если refresh_token не истек и совпадает с тем что в базе — сервер создает access_token и refresh_token, обновляет в базе refresh_token и отдает на клиент. Если refresh_token не валиден просит ввести логин/пароль
4. При инициализации приложения если есть refresh_token — делает тоже что и в 3
А что если access_token не хранить на стороне приложения, а использовать только для одной сесии и с коротким сроком жизни? А хранить refresh_token и каждый раз при инициализации приложения получать новый access_token и refresh_token. Таким образом если ктото украл токены и использовал refresh_token то при запросе пользователя после инициализации или попытке обновить токены, refresh_token не совпадет с тем что в базе и пользователя попросят ввести логин пароль, что приведет к обновлению refresh_token в базе и украденым уже нельзя будет воспользоватся
The iss (issuer) claim identifies the principal that issued the JWT. The processing of this claim is generally application specific. The iss value is a case-sensitive string containing a StringOrURI value. Use of this claim is OPTIONAL.
Вы читали как работает JWT? access token не нужно держать на стороне сервера. Пример использования на сервере:
— создаем токен:
var token = jwt.sign({
userID: '123'
}, 'secret', { expiresIn: '1h' });
— проверяем:
var decoded = jwt.verify(token, 'secret');
// decoded.userID = 123
— access_token не нужно хранить в базе данных, с помощью JWT можно хранить данные в токене — например userId, таким образом при каждом запросе к серверу мы избавляемся от лишнего запроса к базе данных так как ID юзера можно получить из токена
— refresh_token хеш который хранится в базе данных.
1. Сервер получает логин/пароль — создает access_token и refresh_token, сохраняет в базу refresh_token, отдает токены на клиент
2. Клиент использует access_token для доступа к данным пока приложение не будет закрыто, сохраняет refresh_token в хранилище
3. Если получает от сервера сообщение что срок access_token истек — отправляет запрос на авторизацию с refresh_token, если refresh_token не истек и совпадает с тем что в базе — сервер создает access_token и refresh_token, обновляет в базе refresh_token и отдает на клиент. Если refresh_token не валиден просит ввести логин/пароль
4. При инициализации приложения если есть refresh_token — делает тоже что и в 3