Как сервер авторизации JWT и API сервер проводят валидацию токена?

Question

[heducose]

не совсем понятен этот момент.

есть 2 приложения, на разных доменах.
одно - чисто авторизация, выдает токены, регистрирует.
второе - API сервер, откуда клиент запрашивает информацию.

вот пример схемы



как происходит синхронизация данных между эти серверами? это ведь должно происходить мгновенно? или по какому принципу происходит валидация токена?

Answer 1

[Александр Кузнецов]

Вообще, второе приложение (API) должно уметь по данному токену получать пользователя.
По сути, JWT-токен состоит из трех частей:

• Заголовок с алгоритмом
  
• Тело
  
• Подпись
  

В теле, обычно лежит информация вида:

1. Когда выдан
   
2. Срок действия
   
3. Кто выдал
   
4. Публичные метки (роли, идентификатор пользователя и т.п.)
   

API декодирует токен, в зависимости от алгоритма (может быть понадобится p12 - сертификат, все зависит от настроек) и на основание этой информации получает пользователя. Как только у вас истекает время жизни токена, приложение бросает 401 и вам нужно заново получить токен.

Валидация - проверка соответствия тела токена подписи, она происходит посредством механизма подписи, который определяется из первого заголовка. Тут может быть и хэширование ключом, а может и достаточно парольной фразы.

Есть другой вариант, когда сервер авторизации дает два токена, второй - то что называется refresh_token. При такой ситуации, API может запросить новый токен для этого пользователя и дальше общаться через новый токен.

Важно понимать, что использует клиент в качестве библиотеки для JWT-аутентификации (а API - это клиент), как она (библиотека) может работать.

Comments

[heducose]

Так в том-то и дело, что тело токена использует данные, уникальные для каждой регистрации, например таймштамп. Откуда эти данные у API сервера? Ниоткуда, если я сам их не буду отдавать туда. Так какой тогда смысл делать двойную работу, не понимаю. Мне получается нужно теперь имплементировать не на одном сервере, а на обоих?

[Александр Кузнецов]

heducose: На всякий случай: https://tools.ietf.org/html/rfc7519#section-4.1 , Registered Claim Names
Касаемо таймштамп. Вы говорите про метку (claim) exp, без которого смысла в токене нет (в общем случае).
Данная метка - это сумма текущего времени сервера авторизации и TTL (Time to live — время жизни).

что тело токена использует данные, уникальные для каждой регистрации, например таймштамп. Откуда эти данные у API сервера

НЕ понятен вопрос. Если мы преобразуем тело токена в "читабельный" формат, то получим что-то вида:

{
	"roles": { "0": "ROLE_ADMIN", "2": "ROLE_SONATA_ADMIN", "3": "ROLE_USER" },  //non standart
	"username": "admin", //non standart
	"iat": 1500453118, // optional
	"exp": 1500456718 // required
}

Преобразование это не требует каких-то секретных данных и любой токен можно разложить на части.

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

Вы про это спрашивали?

[heducose]

Александр Кузнецов: спасибо за инфу. Возможно я путанно спрашиваю. Но смотрите как у меня сейчас имплементировано в одном проекте.

passport-jwt проводит ExtractJwt используя секрет и сверяет ID пользователя в своей базе. и на основании этого подтверждает, что да, токен правильный и дает доступ в ресурсу. А как это будет выглядеть если я разделю приложения - не понимаю! Вот мой вопрос. Регистрация (и база) на одном сервере, а вот эта проверка которую я написал - на другом.

[Александр Кузнецов]

heducose: Проверку валидности на клиенте нужно проводить без исходных данных, т.е. не обращаясь в приложение (источник и т.к.), выдавший данный токен.

Для проверки валидности токена используется 1 часть токена, где указан тип алгоритма хэширования, третья часть токена, где указан хэш токена, сгенерированный на основание алгоритма из первой части.

Представим, вы шифруете через HMAC:

// sign with default (HMAC SHA256)
var jwt = require('jsonwebtoken');
var token = jwt.sign({ foo: 'bar' }, 'shhhhh');

,
то проверить токен можно просто:

// verify a token symmetric - synchronous
var decoded = jwt.verify(token, 'shhhhh');
console.log(decoded.foo) // bar

Т.е., по сути, клиенту нужно знать только пароль: shhhhh

Если мы будем говорит про RS256, к примеру, то тут уже нужно иметь ключи шифрования (RSA), там немного посложнее.

[heducose]

Александр Кузнецов: извиняюсь за глупый встречный вопрос - почему вы говорите о проверке на клиенте (т.е. браузере юзера?)? Но в целом, насколько я понял - для проверки токена на третьей стороне (на моем API сервере), этой стороне достаточно знать секрет?

[Александр Кузнецов]

heducose: Под клиентом я подразумеваю приложение, использующее сервер авторизации, а не браузер. Клиент JWT-сервера.

Но в целом, насколько я понял - для проверки токена на третьей стороне (на моем API сервере), этой стороне достаточно знать секрет?

Если вы используете HMAC-подобное хэширование, то да, обычно там используется только секрет.