Ані автентифікація за допомогою реп'яхів, ані JWT не захищенні від MITM атак. Для цього є https. В першому випадку, можна перехопити id сессії, а другому - JWT.
З Вашого опису я зрозумів, що JWT використовувався майже так само як і session id - валідація стану автентифікації. Переваги JWT полягають у тому, що на відміну від session id, для його валідації не треба лізти до бази (чи кешу), а також, забута Вами головна "фішка", він може містити довільні дані, а id сессії - лише айді сессії. Зазвачай ці дані - інформація про юзера.
Розглянемо наступний приклад: існує захищенний API ендпоїнт для запитів імені поточного (автентифікованого) юзера.
1) Session Id
1.1) Юзер автентифікується, отримує session_id. Робиться запис до бази {session_id, user_id}.
1.2) Юзер надсилає запит з session_id
1.3) Сервер перевіряє чи існує session_id в базі/кеші, та який user_id цій сессії відповідає
1.4) Сервер робит запит про інформацію юзера user_name знову з бази і повертає користувачеві
З мінусів:
- 2 додаткових запити до бази
- треба пільнувати старі сессії, інвалідувати їх
З плюсів:
- відомо які сесії активні
- логування сесії "за дизайном"
2) JWT
2.1) Юзер автентифікується, отримує токен JWT(user_name) ~ (далі) JWT з зашифрованим user_name
2.2) Юзер надсилає запит з JWT
2.3) Сервер дешифрує JWT, отримує user_name і надсилає назад
З мінусів:
- розмір JWT більший і пропорційний кількості додаткових даних вкладених до нього
- додаткові витрати на шифрування/дешифрування
З плюсів:
- довільні дані про юзера одразу в токені
- жодних запитів до бази для перевірки стану автентифікації
- при добрій імплементації, можна також позбутися запитів до бази для авторизації
