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

Question

heducose @heducose

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

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

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

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

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

Вопрос задан более трёх лет назад
4085 просмотров

Комментировать

Подписаться 3 Оценить Комментировать

Решения вопроса 1

6 комментариев

heducose @heducose Автор вопроса

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

Написано более трёх лет назад
Александр Кузнецов @DarkRaven
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 @heducose Автор вопроса

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

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

Написано более трёх лет назад
Александр Кузнецов @DarkRaven
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 @heducose Автор вопроса

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

Написано более трёх лет назад
Александр Кузнецов @DarkRaven

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

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

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

Написано более трёх лет назад

Пригласить эксперта

Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации

Похожие вопросы

WordPress

+2 ещё

Средний
Как сделать автоматический выбор региона по IP в Wordpress?
- 1 подписчик
- вчера
- 46 просмотров
2

ответа
PHP

+1 ещё

Простой
Почему не работает JWT поверка?
- 1 подписчик
- вчера
- 67 просмотров
0

ответов
Python

+2 ещё

Простой
OK.RU, API приложений, не могу загрузить видео: User must grant an access to permission 'VIDEO_CONTENT'". Как получить этиправа для приложения?
- 1 подписчик
- 21 апр.
- 54 просмотра
1

ответ
API

+2 ещё

Средний
Реально ли возродить сервис vk wikiposter?
- 1 подписчик
- 20 апр.
- 53 просмотра
0

ответов
Веб-разработка

+1 ещё

Простой
Как правильно в api реализовать систему уведомлений на сайт и в тг бота?
- 4 подписчика
- 14 апр.
- 1100 просмотров
2

ответа
Фронтенд

+1 ещё

Простой
Как понять токен рефрешится или нет?
- 1 подписчик
- 11 апр.
- 64 просмотра
1

ответ
Windows

+2 ещё

Простой
Как получить хендл без OpenProcess?
- 1 подписчик
- 11 апр.
- 112 просмотров
1

ответ
Telegram

+1 ещё

Средний
Почему my.telegram.org/apps не дает создать доступ из-за ошибки — ERROR?
- 1 подписчик
- 09 апр.
- 111 просмотров
0

ответов
PHP

+2 ещё

Средний
Как правильно сделать синхронизацию чатов телеграм бота с ОЛ?
- 1 подписчик
- 09 апр.
- 91 просмотр
0

ответов
API

+2 ещё

Простой
Не существует ли рабочих card2card с предзаполненными данными получателя?
- 1 подписчик
- 07 апр.
- 72 просмотра
0

ответов
Показать ещё Загружается…

JavaScript разработчик на интеграцию API деловых линий с AMO CRM удаленно

Sky Cargo Service

от 25 000 ₽

QA engineer (настройка автоматизации на PyTest), тесты API, UI.

HR BIG G

До 250 000 ₽

Intern System Analyst

Media Code

До 30 000 ₽

Анимация логотипа

24 апр. 2024, в 00:08

20000 руб./за проект

Разработка дизайна раздела «Статьи» на сайте «Мир отходов»

23 апр. 2024, в 23:01

10000 руб./за проект

Дизайн личного кабинета (клиентская часть)

23 апр. 2024, в 22:37

500 руб./в час

Answer 1 · 2017-07-19 07:43:09

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

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

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

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

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

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

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

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

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

Войдите, чтобы написать ответ

Минуточку внимания

Войдите на сайт